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. 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.... Still, I wonder if I should hold off on "-d daxinherit" patch until we have thought through things like reflink conflicts, for now. (though again, mkfs is "perfectly capapable" of making a consistent reflink+dax filesystem, it's just that no kernel can mount it today...) -Eric
