Date:   Wed, 17 Oct 2018 12:52:54 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Eric Sandeen <sandeen@...deen.net>
Cc:     zwisler@...nel.org, Christoph Hellwig <hch@....de>,
        Jan Kara <jack@...e.cz>, linux-xfs <linux-xfs@...r.kernel.org>,
        linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 0/3] ext2, ext4, xfs: hard fail dax mount on unsupported devices

On Wed, Oct 17, 2018 at 12:42 PM Eric Sandeen <sandeen@...deen.net> wrote:
>
>
>
> On 10/13/18 11:05 AM, Ross Zwisler wrote:
> > On Fri, Oct 12, 2018 at 2:21 AM Christoph Hellwig <hch@....de> wrote:
> >>
> >> On Thu, Oct 11, 2018 at 01:38:34PM -0500, Eric Sandeen wrote:
> >>>> The different behavior between filesystems was confusing customers so
> >>>> we had to align them, then the question was which default to pick.
> >>>> Honestly, we came to the decision to bring ext4 in line with the xfs
> >>>> behavior because we thought that would be easier than the alternative.
> >>>> Dave and Christoph made repeated arguments that DAX is just a hidden
> >>>> performance optimization that no application should rely on, so we
> >>>> went the path of least resistance and changed the ext4 default.
> >>>
> >>> Ok, well, I guess we'd better reconcile "it's a hidden performance hint"
> >>> with "if the administrator asked they must receive..." before making this
> >>> change... cc: hch for bonus input.
> >>
> >> I don't really care too mouch on the mount options, the important bit
> >> was the application behavior.
> >>
> >> I fully agree with Dan that we should have the same behavior for every
> >> file system, though.
> >
> > One factor that might influence this is how we expect users to detect
> > whether or not DAX is being used, and whether that can vary per-inode
> > within a filesystem.  If we choose to only have the mount option then
> > I agree that a hard failure when -o dax doesn't work seems fine.  And
> > of course keeping the filesystems behaving the same is desirable.
> >
> > If we eventually do go back to having a per-inode DAX option, though,
> > the mount option becomes a hint as to what the default behavior is,
> > and the user will need another way to detect whether or not DAX is
> > being used for a given inode.  In that case having the mount option
> > fail loudly isn't as important because all we've really changed is the
> > filesystem's default, and the application will still need a consistent
> > way of detecting whether the inode they are actually using is DAX or
> > not.
> >
> > I'm not sure if per-inode DAX is still a goal for anyone.  If not,
> > then sure, using the DAX mount option as the one source of truth and
> > making it a hard failure when it doesn't work seems reasonable.
>
> 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.

+1 from me. The mount option is a blunt global override and we should
proceed with the finer-grained enabling. DAX is not guaranteed to have
neutral to positive performance impact so it should be enabled
consciously.

Powered by blists - more mailing lists