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

From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>, Anthony Iliopoulos <ailiop@suse.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 0/6] xfsprogs: blockdev dax detection and warnings
Date: Tue, 25 Aug 2020 08:59:39 -0500	[thread overview]
Message-ID: <4aa834dd-5220-6312-e28f-1a94a56b1cc0@sandeen.net> (raw)
In-Reply-To: <20200824225533.GA12131@dread.disaster.area>

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