On Wed, Oct 17, 2018 at 2:31 PM Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: > > Eric Sandeen <sandeen@xxxxxxxxxxx> writes: > > > I've been thinking about the per-inode stuff a bit, and while I don't know > > how to resolve some of the trickier issues, at least the expected behavior > > seems like something we can narrow down and specify. > > > > Because it's an on-disk flag (in xfs today, in any case) it seems that > > the only sane behavior to expect is either/or, i.e.: > > > > Mount option: All files always dax, per-inode flags ignored (or rejected) > > Per-inode: Mount option cannot be specified; only inodes explicitly flagged are dax > > > > Think about it; what would mount-option-plus-per-inode mean? We have > > no "negative" dax flag, so while mount-option-with-flag surely means > > "dax", what the heck does mount-option-without-flag mean, and how is it > > distinguishable from mount option only? > > > > I submit that flags can only have meaning w/o the fs-wide mount option > > enabled, so the question of "should we hard fail mount -o dax for devices > > that cannot support it" seems to be orthogonal to the per-inode question. > > > > i.e. mount -o dax really can only mean "I want dax on everything" and so > > again, I think we probably need to fail the mount if that can't be honored. > > I hate to even open up this can of worms, but what about killing the dax > mount option? > > To quote Christoph: > How does an application "make use of DAX"? What actual user visible > semantics are associated with a file that has this flag set? > > We're already talking about making caching decisions automatically, so > does DAX even mean anything at that point? If the storage and the file > system support it, enable it. > > From what we've seen so far, aplications want: > 1) to be able to make data persistent from userspace > For this, we have MAP_SYNC. > 2) to determine whether or not page cache will be used > For this, we have O_DIRECT for read/write access, and MAP_SYNC for > mmap access (and maybe a third option coming, we'll see). As Jan has said, it's not safe to assume that 'no page cache' is implied with MAP_SYNC. It's a side effect not a contract of the current implementation. > The only thing users gain from a mount option is the ability to turn OFF > dax. I suppose there might be a use case that wants this, but I'm not > aware of it. I think we're stuck with it as many scripts would break if it ever went completely away. However, we could mark it deprecated / ignored provided we had a way for applications to query and override if DAX is enabled. I also think it's important to keep separate the dax-mmap behavior from the dax-read/write behavior. dax-mmap is where an application would make different decisions if it can get a mapping without page cache, dax-read/write does not appear to have any justification to be advertised because the application would not do anything different whether that is present or not.
