Re: [RFC PATCH 2/2] xfs: do not allow reflinking inodes with the dax flag set

[Eric Sandeen <sandeen@redhat.com>]

On 12/2/20 4:22 AM, Christoph Hellwig wrote:
> On Tue, Dec 01, 2020 at 01:20:55PM -0600, Eric Sandeen wrote:
>> Today, xfs_reflink_remap_prep() will reject inodes which are in the CPU
>> direct access state, i.e. IS_DAX() is true.  However, it is possible to
>> have inodes with the XFS_DIFLAG2_DAX set, but which are not activated as
>> dax, due to the dax=never mount option, or due to the flag being set after
>> the inode was loaded.
>>
>> To avoid confusion and make the lack of dax+reflink crystal clear for the
>> user, reject reflink requests for both IS_DAX and XFS_DIFLAG2_DAX inodes.
>>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>> ---
>>
>> This is RFC because as Darrick says, it introduces a new failure mode for
>> reflink. On the flip side, today the user can reflink a chattr +x'd file,
>> but cannot chattr +x a reflinked file, which seems a best a bit asymmetrical
>> and confusing... see xfs_ioctl_setattr_xflags()
> 
> This seems confusing.  IMHO for now we should just for non-dax access
> to any reflink file even if XFS_DIFLAG2_DAX is set.  The only place
> where we cannot do that is if a file has XFS_DIFLAG2_DAX set and is in
> use and we want to reflink it.  Note that "in use" is kinda murky and
> potentially racy.  So IMHO not allowing reflink when XFS_DIFLAG2_DAX
> is set and dax=never is not set makes sense, but we should not go
> further.

Hm, trying to parse that...

Would it be correct to restate your last sentence as "Disallowing reflink
when XFS_DIFLAG2_DAX is set and dax=inode is set makes sense?"

If so, then the only change you're suggesting to this patch is to /allow/
reflinking if dax=never is set?

I just figured a very clear statementa bout incompatible flags was simplest,
but I get it that it's overly restrictive, functionally.

Thanks,
-Eric