Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1728473

Re: [PATCH 0/9] add ext4 per-inode DAX flag

Show all headers | View raw

On Fri, Sep 08, 2017 at 08:12:01AM +1000, Dave Chinner wrote:
> On Thu, Sep 07, 2017 at 03:51:48PM -0600, Ross Zwisler wrote:
> > On Thu, Sep 07, 2017 at 03:26:10PM -0600, Andreas Dilger wrote:
> > > However, I wonder if this could
> > > be prevented at runtime, and only allow S_DAX to be set when the inode is
> > > first instantiated, and wouldn't be allowed to change after that?  Setting
> > > or clearing the per-inode DAX flag might still be allowed, but it wouldn't
> > > be enabled until the inode is next fetched into cache?  Similarly, for
> > > inodes that have conflicting features (e.g. inline data or encryption)
> > > would not be allowed to enable S_DAX.
> > 
> > Ooh, this seems interesting.  This would ensure that S_DAX transitions
> > couldn't ever race with I/Os or mmaps().  I had some other ideas for how to
> > handle this, but I think your idea is more promising. :)
> 
> IMO, that's an awful admin interface - it can't be done on demand
> (i.e. when needed) because we can't force an inode to be evicted
> from the cache. And then we have the "why the hell did that just
> change" problem if an inode is evicted due to memory pressure and
> then immediately reinstantiated by the running workload. That's a
> recipe for driving admins insane...
> 
> > I guess with this solution we'd need:
> > 
> > a) A good way of letting the user detect the state where they had set the DAX
> > inode flag, but that it wasn't yet in use by the inode.
> > 
> > b) A reliable way of flushing the inode from the filesystem cache, so that the
> > next time an open() happens they get the new behavior.  The way I usually do
> > this is via umount/remount, but there is probably already a way to do this?
> 
> Not if it's referenced. And if it's not referenced, then the only
> hammer we have is Brutus^Wdrop_caches. That's not an option for
> production machines.
> 
> Neat idea, but one I'd already thought of and discarded as "not
> practical from an admin perspective".

Okay, so other ideas (which you have also probably already though of) include:

1) Just return -EBUSY if anyone tries to change the DAX flag of an inode with
open mappings or any open file handles.  To prevent TOCTOU races we'd have to
do some additional locking while actually changing the flag.

2) Be more drastic and follow the flow of ext4 file based encryption, only
allowing the inode flag to be set by an admin on an empty directory.  Files in
that directory will inherit it when they are created, and we don't provide a
way to clear.  If you want your file to not use DAX, move it to a different
directory (which I think for ext4 encryption turns it into a new inode).

Other ideas?

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 0/9] add ext4 per-inode DAX flag Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-06 00:40 +0200
  [PATCH 9/9] ext4: add per-inode DAX flag Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-06 00:40 +0200
  [PATCH 2/9] xfs: always use DAX if mount option is used Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-06 00:40 +0200
  [PATCH 4/9] ext4: add ext4_should_use_dax() Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-06 00:40 +0200
  [PATCH 8/9] ext4: add sanity check for encryption + DAX Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-06 00:40 +0200
  [PATCH 5/9] ext4: ext4_change_inode_journal_flag error handling Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-06 00:40 +0200
  [PATCH 7/9] ext4: prevent data corruption with inline data + DAX Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-06 00:40 +0200
    Re: [PATCH 7/9] ext4: prevent data corruption with inline data + DAX Andreas Dilger <adilger@dilger.ca> - 2017-09-06 23:00 +0200
      Re: [PATCH 7/9] ext4: prevent data corruption with inline data + DAX Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-07 01:20 +0200
  [PATCH 1/9] ext4: remove duplicate extended attributes defs Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-06 00:40 +0200
    Re: [PATCH 1/9] ext4: remove duplicate extended attributes defs Jan Kara <jack@suse.cz> - 2017-09-06 09:30 +0200
  [PATCH 6/9] ext4: safely transition S_DAX on journaling changes Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-06 00:40 +0200
    Re: [PATCH 6/9] ext4: safely transition S_DAX on journaling changes Jan Kara <jack@suse.cz> - 2017-09-06 11:50 +0200
      Re: [PATCH 6/9] ext4: safely transition S_DAX on journaling changes Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-06 19:10 +0200
  Re: [PATCH 0/9] add ext4 per-inode DAX flag Eric Sandeen <esandeen@redhat.com> - 2017-09-06 04:20 +0200
    Re: [PATCH 0/9] add ext4 per-inode DAX flag Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-06 19:10 +0200
      Re: [PATCH 0/9] add ext4 per-inode DAX flag Dan Williams <dan.j.williams@intel.com> - 2017-09-07 23:00 +0200
        Re: [PATCH 0/9] add ext4 per-inode DAX flag Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-07 23:20 +0200
          Re: [PATCH 0/9] add ext4 per-inode DAX flag Andreas Dilger <adilger@dilger.ca> - 2017-09-07 23:30 +0200
            Re: [PATCH 0/9] add ext4 per-inode DAX flag Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-08 00:00 +0200
              Re: [PATCH 0/9] add ext4 per-inode DAX flag Ross Zwisler <ross.zwisler@linux.intel.com> - 2017-09-08 00:20 +0200
                Re: [PATCH 0/9] add ext4 per-inode DAX flag Dave Chinner <david@fromorbit.com> - 2017-09-08 01:30 +0200
                Re: [PATCH 0/9] add ext4 per-inode DAX flag Jan Kara <jack@suse.cz> - 2017-09-08 11:50 +0200
                Re: [PATCH 0/9] add ext4 per-inode DAX flag Theodore Ts'o <tytso@mit.edu> - 2017-09-08 17:40 +0200
              Re: [PATCH 0/9] add ext4 per-inode DAX flag Dave Chinner <david@fromorbit.com> - 2017-09-08 00:20 +0200

csiph-web