On Thu, Sep 15, 2016 at 10:36 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Thu, Sep 15, 2016 at 07:04:27PM -0700, Dan Williams wrote: >> On Thu, Sep 15, 2016 at 6:24 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: >> > On Thu, Sep 15, 2016 at 05:16:42PM -0700, Dan Williams wrote: >> >> On Thu, Sep 15, 2016 at 4:07 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: >> >> > On Thu, Sep 15, 2016 at 10:01:03AM -0700, Dan Williams wrote: >> >> >> On Thu, Sep 15, 2016 at 1:26 AM, Christoph Hellwig <hch@xxxxxx> wrote: >> >> >> > On Wed, Sep 14, 2016 at 11:54:38PM -0700, Dan Williams wrote: >> >> >> >> The DAX property, page cache bypass, of a VMA is only detectable via the >> >> >> >> vma_is_dax() helper to check the S_DAX inode flag. However, this is >> >> >> >> only available internal to the kernel and is a property that userspace >> >> >> >> applications would like to interrogate. >> >> >> > >> >> >> > They have absolutely no business knowing such an implementation detail. >> >> >> >> >> >> Hasn't that train already left the station with FS_XFLAG_DAX? >> >> > >> >> > No, that's an admin flag, not a runtime hint for applications. Just >> >> > because that flag is set on an inode, it does not mean that DAX is >> >> > actually in use - it will be ignored if the backing dev is not dax >> >> > capable. >> >> >> >> What's the point of an admin flag if an admin can't do cat /proc/<pid >> >> of interest>/smaps, or some other mechanism, to validate that the >> >> setting the admin cares about is in effect? >> > >> > Sorry, I don't follow - why would you be looking at mapping file >> > regions in /proc to determine if some file somewhere in a filesystem >> > has a specific flag set on it or not? >> > >> > FS_XFLAG_DAX is an inode attribute flag, not something you can >> > query or administrate through mmap: >> > >> > I.e. >> > # xfs_io -c "lsattr" -c "chattr +x" -c lsattr -c "chattr -x" -c "lsattr" foo >> > --------------- foo >> > --------------x foo >> > --------------- foo >> > # >> > >> > What happens when that flag is set on an inode is determined by a >> > whole bunch of other things that are completely separate to the >> > management of the inode flag itself. >> >> Right, I understand that, but how does an admin audit those "bunch of >> other things" > > Filesystem mounts checks all the various stuff that determines > whether DAX can be used. It logs to the console that it is "Dax > capable". Any file that then has FS_XFLAG_DAX set will result in DAX > being used. There is no other possibility when these two things are > reported. > > /me points at runtime diagnostic tracepoints like > trace_xfs_file_dax_read() and notes that dax is sadly lacking in > diagnostic tracepoints. > > Besides, userspace can't do anything useful with this information, > because the FS_XFLAG_DAX can be changed /at any time/ by an admin. > And the filesystem is free to remove it at any time, too, if it > needs to (e.g. file gets reflinked or snapshotted). > > That's right, an inode can dynamically change from DAX to non-DAX > underneath the application, and the application /will not notice/. > That's because changing the flag will sync and invalidate the > existing mappings and the next application access will simply fault > it back in using whatever mechanism the inode is now configured > with. > > Plain and simple: userspace has absolutely no fucking idea of > whether DAX is enabled or not, and whatever the kernel returns to > userspace above the DAX configuration is stale before it even got > out of the kernel.... smaps is already known to be an ephemeral interface, but we output useful information there nonetheless. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
