Re: [PATCH 0/6] xfsprogs: blockdev dax detection and warnings

[Anthony Iliopoulos <ailiop@suse.com>]

On Tue, Aug 25, 2020 at 08:59:39AM -0500, Eric Sandeen wrote:
> On 8/24/20 5:55 PM, Dave Chinner wrote:
> > I agree that mkfs needs to be aware of DAX capability of the block
> > device, but that capability existing should not cause mkfs to fail.
> > If we want users to be able to direct mkfs to to create a DAX
> > capable filesystem then adding a -d dax option would be a better
> > idea. This would direct mkfs to align/size all the data options to
> > use a DAX compatible topology if blkid supports reporting the DAX
> > topology. It would also do things like turn off reflink (until that
> > is supported w/ DAX), etc.
> > 
> > i.e. if the user knows they are going to use DAX (and they will)
> > then they can tell mkfs to make a DAX compatible filesystem.
> 
> FWIW, Darrick /just/ added a -d daxinherit option, though all it does
> now is set the inheritable dax flag on the root dir, it doesn't enforce
> things like page vs block size, etc.

I am aware of that patch, but I considered the option to be somewhat
orthogonal, given that FS_XFLAG_DAX can be set (and inherited)
irrespective of dax support in the block device (and overridden via
mount opts if need be), so I didn't want to overload daxinherit.

> That change is currently staged in my local tree.
> 
> I suppose we could condition that on other requirements, although we've
> always had the ability to mkfs a filesystem that can't necessarily be
> used on the current machine - i.e. you can make a 64k block size filesystem
> on a 4k page machine, etc.  So I'm not sure we want to tie mkfs abilities
> to the current mkfs environment....

Agreed, so I suppose any dax option should be an opt-in, e.g. similar to
the -d dax=1 proposal. That won't prevent users from neglecting it and
creating a fs which will be later incompatible with -o dax, but that's a
different story I guess..

- Anthony