On Tue, May 17, 2022 at 05:01:07PM +1000, Dave Chinner wrote: > From: Dave Chinner <dchinner@xxxxxxxxxx> > > LVM/DM has conniptions when you try to use snapshots on a device > that has DAX capability. It first sets up the underlying device as a > DAX capable mapping (type 3 or DM_TYPE_DAX_BIO_BASED) but because > snapshots require COW and shared mappings, it isn't supported on DAX > capable devices. Hence creating the snapshot device fails because it > requires a type 1 (DM_TYPE_BIO_BASED) device and DM can't change > types on a loaded mapping. > > Hence we get this obscure error message in the log: > > device-mapper: ioctl: can't change device type (old=3 vs new=1) after initial table load. > > and these obscure, unhelpful error messages from the LVM command > outputs: > > device-mapper: reload ioctl on (251:0) failed: Invalid argument > Failed to suspend logical volume vg_081/base_081. > Device vg_081-base_081-real (251:1) is used by another device. > Failed to revert logical volume vg_081/base_081. > Aborting. Manual intervention required. > Failed to create snapshot > > How to turn off DAX capability is not documented in dmsetup or LVM > man pages, nor is dax mentioned anywhere in > Documentation/admin/device-mapper/ so I have no idea how to tell > LVM/DM "don't try to enable DAX support!". > > As such, if the uderlying block device is dax capable, skip this > test. > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> Self nack this one for now - this doesn't seem to be working properly in the case of "no dax mount option" i.e. the default of dax=inode. I think in that case __scratch_uses_fsdax() has to return "no" so that the support check then falls through to __scratch_dev_has_dax() to determine if DAX will be used or not. I missed this because I have dax=never set by default on many of my fstests configs because I use a mix of ramdisk and normal block devices and I don't want them to use DAX at all when operating on a ramdisk unless I'm running an explicit DAX-enabled test config. I'll send an update to fix this soon. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
