I've been analyzing why fstest generic/081 fails when the backing device is
capable of DAX. The problem boils down to the failure of:
lvm vgcreate -f vg0 /dev/pmem0
lvm lvcreate -L 128M -n lv0 vg0
lvm lvcreate -s -L 4M -n snap0 vg0/lv0
The last command fails like:
device-mapper: reload ioctl on (253:0) failed: Invalid argument
Failed to lock logical volume vg0/lv0.
Aborting. Manual intervention required.
And the core of the problem is that volume vg0/lv0 is originally of
DM_TYPE_DAX_BIO_BASED type but when the snapshot gets created, we try to
switch it to DM_TYPE_BIO_BASED because now the device stops supporting DAX.
The problem seems to be introduced by Ross' commit dbc626597 "dm: prevent
DAX mounts if not supported".
The question is whether / how this should be fixed. The current inability
to create snapshots of DAX-capable devices looks weird and the cryptic
failure makes it even worse (it took me quite a while to understand what is
failing and why). OTOH I see the rationale behind Ross' change as well.
Jan Kara <jack(a)suse.com>
SUSE Labs, CR