linux-ext4 - Re: [PATCH 0/3] ext2, ext4, xfs: hard fail dax mount on unsupported devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 13 Oct 2018 10:05:33 -0600
From:   Ross Zwisler <zwisler@...nel.org>
To:     Christoph Hellwig <hch@....de>
Cc:     sandeen@...deen.net, 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 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.