Date:   Wed, 17 Oct 2018 14:42:36 -0500
From:   Eric Sandeen <sandeen@...deen.net>
To:     Ross Zwisler <zwisler@...nel.org>, Christoph Hellwig <hch@....de>
Cc:     Dan Williams <dan.j.williams@...el.com>, 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 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.

-Eric

Powered by blists - more mailing lists