Re: direct_access, pinning and truncation

[Dave Chinner <david@fromorbit.com>]

On Thu, Oct 09, 2014 at 11:25:24AM -0400, Matthew Wilcox wrote:
> On Thu, Oct 09, 2014 at 12:10:38PM +1100, Dave Chinner wrote:
> > On Wed, Oct 08, 2014 at 03:05:23PM -0400, Matthew Wilcox wrote:
> > > 
> > > One of the things on my todo list is making O_DIRECT work to a
> > > memory-mapped direct_access file.
> > 
> > I don't understand the motivation or the use case: O_DIRECT is
> > purely for bypassing the page cache, and DAX already bypasses the
> > page cache.  What difference is there between the DAX read/write
> > path and a DAX-based O_DIRECT IO path, and why doesn't just ignoring
> > O_DIRECT for DAX enabled filesystems simply do what you need?
> 
> There are two filesystems involved ... if both (or neither!) are DAX,
> everything's fine.  The problem comes when you do things this way around:
> 
> int cachefd = open("/dax/cache", O_RDWR);
> int datafd = open("/nfs/bigdata", O_RDWR | O_DIRECT);
> void *cache = mmap(NULL, 1024 * 1024 * 1024, PROT_READ | PROT_WRITE,
> 		MAP_SHARED, cachefd, 0);
> read(datafd, cache, 1024 * 1024);
> 
> The non-DAX filesystem needs to pin pages from the DAX filesystem while
> they're under I/O.

OK, that's what I was missing - it's not direct IO into/out of the
DAX filesystem - it's when you use the mmap()d DAX pages as the
source/destination of said direct IO.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com