[0/2] xfs: fix up some reflink+dax interactions

Message

Eric Sandeen Dec. 1, 2020, 7:10 p.m. UTC

dax behavior has changed semi-recently, most notably that per-inode dax
flags are back, which opens the possibility of dax-capable files existing on
reflink-capable filesystems.

While we still have a reflink-vs-dax-on-the-same-file incompatibilty, and for
the most part this is handled correctly, there are a couple of known issues:

1) xfs_dinode_verify will trap an inode with reflink+dax flags as corrupted;
   this needs to be removed, because we actually can get into this state today,
   and eventually that state will be supported in future kernels.

2) (more RFC) until we actually support reflink+dax files, perhaps we should
   prevent the flags from co-existing in a kernel that cannot support both
   states.  patch 2 stops us from reflinking files with the dax flag set,
   whether or not the file is actually "in the CPU direct access state"

-Eric

Comments

Eric Sandeen Dec. 1, 2020, 7:23 p.m. UTC | #1

On 12/1/20 1:10 PM, Eric Sandeen wrote:
> dax behavior has changed semi-recently, most notably that per-inode dax
> flags are back, which opens the possibility of dax-capable files existing on
> reflink-capable filesystems.
> 
> While we still have a reflink-vs-dax-on-the-same-file incompatibilty, and for
> the most part this is handled correctly, there are a couple of known issues:
> 
> 1) xfs_dinode_verify will trap an inode with reflink+dax flags as corrupted;
>    this needs to be removed, because we actually can get into this state today,
>    and eventually that state will be supported in future kernels.
> 
> 2) (more RFC) until we actually support reflink+dax files, perhaps we should
>    prevent the flags from co-existing in a kernel that cannot support both
>    states.  patch 2 stops us from reflinking files with the dax flag set,
>    whether or not the file is actually "in the CPU direct access state"
> 
> -Eric

Also yes I owe xfstests for these but wanted to see if the patches fly, first.

-Eric