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

From: Eric Sandeen <sandeen@sandeen.net>
To: Anthony Iliopoulos <ailiop@suse.com>
Cc: Dave Chinner <david@fromorbit.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 0/6] xfsprogs: blockdev dax detection and warnings
Date: Tue, 25 Aug 2020 12:32:07 -0500	[thread overview]
Message-ID: <2200404f-acdb-690c-a0ac-540f7d93902f@sandeen.net> (raw)
In-Reply-To: <20200825150915.GD3357@technoir>

On 8/25/20 10:09 AM, Anthony Iliopoulos wrote:
> 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.

OK fair enough.

>> 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..

I guess my overarching desire here is to not try to predict too much, or to
make predictions that won't stand the test of time. Inferring what the admin
wants can be tricky.  :)  

I also want to be consistent; i.e. today we can mkfs a 64k block filesystem
on a 4k block machine, and no warning is emitted. If we mkfs a V5/CRC filesystem
or a reflink filesystem on an old kernel that doesn't support it, no warning is
emitted.

If we're going to warn every time when "this filesystem can't be used under the
currently running kernel" then there are quite a lot of cases to handle... I
don't want to warn about some things and not others, so we need to decide if
this is actually something we want to do in general, not just for dax.  I'm 
somewhat disinclined, TBH, and would rather rely on a mount failure to alert
the admin to the problem.  (It's not like there are a lot of resources invested
between mkfs & mount).

I'll reread this thread & Dave's responses and give this some more thought.

Thanks,
-Eric

> - Anthony
> 