Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S943025AbcJ0OjF (ORCPT ); Thu, 27 Oct 2016 10:39:05 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:38646 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S942862AbcJ0OjA (ORCPT ); Thu, 27 Oct 2016 10:39:00 -0400 Subject: Re: [PATCH 0/3] iopmem : A block device for PCIe memory To: Christoph Hellwig , Dave Chinner References: <1476826937-20665-1-git-send-email-sbates@raithlin.com> <20161019184814.GC16550@cgy1-donard.priv.deltatee.com> <20161020232239.GQ23194@dastard> <20161021095714.GA12209@infradead.org> Cc: jgunthorpe@obsidianresearch.com, sbates@raithin.com, "Raj, Ashok" , haggaie@mellanox.com, linux-rdma@vger.kernel.org, "linux-nvdimm@lists.01.org" , Jonathan Corbet , "linux-kernel@vger.kernel.org" , jim.macdonald@everspin.com, Stephen Bates , linux-block@vger.kernel.org, Linux MM , Jens Axboe , David Woodhouse From: Sagi Grimberg Message-ID: <76e957c9-8002-5a46-8111-269bb0401718@grimberg.me> Date: Thu, 27 Oct 2016 13:22:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161021095714.GA12209@infradead.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1018 Lines: 23 >> You do realise that local filesystems can silently change the >> location of file data at any point in time, so there is no such >> thing as a "stable mapping" of file data to block device addresses >> in userspace? >> >> If you want remote access to the blocks owned and controlled by a >> filesystem, then you need to use a filesystem with a remote locking >> mechanism to allow co-ordinated, coherent access to the data in >> those blocks. Anything else is just asking for ongoing, unfixable >> filesystem corruption or data leakage problems (i.e. security >> issues). > > And at least for XFS we have such a mechanism :) E.g. I have a > prototype of a pNFS layout that uses XFS+DAX to allow clients to do > RDMA directly to XFS files, with the same locking mechanism we use > for the current block and scsi layout in xfs_pnfs.c. Christoph, did you manage to leap to the future and solve the RDMA persistency hole? :) e.g. what happens with O_DSYNC in this model? Or you did a message exchange for commits?