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
