| Message ID | 20220517070111.1381936-9-david@fromorbit.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fstests: fixes and more fixes... | expand |
On Tue, May 17, 2022 at 05:01:07PM +1000, Dave Chinner wrote: > From: Dave Chinner <dchinner@redhat.com> > > 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@redhat.com> 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.
diff --git a/common/rc b/common/rc index 4201a059..f5ead044 100644 --- a/common/rc +++ b/common/rc @@ -2167,7 +2167,7 @@ _require_sane_bdev_flush() # 3. "dax=inode" or nothing means "use scratch dev capability" to # determine whether DAX is going to be used. # -# Returns 0 if DAX will be used, 1 if DAX is not going to be used. +# Returns 0 if the filesytem will use DAX, 1 if it won't. __scratch_uses_fsdax() { local ops=$(_normalize_mount_options "$MOUNT_OPTIONS") @@ -2175,9 +2175,19 @@ __scratch_uses_fsdax() echo $ops | egrep -qw "dax(=always| |$)" && return 0 echo $ops | grep -qw "dax=never" && return 1 + return 0 +} + +# Determine if the scratch device is DAX capable. Every if the fs is not +# using DAX, we still can't use certain device mapper targets if the block +# device is DAX capable. hence the check needs to be separat from the FS +# capability. +__scratch_dev_has_dax() +{ local sysfs="/sys/block/$(_short_dev $SCRATCH_DEV)" test -e "${sysfs}/dax" && return 0 test "$(cat "${sysfs}/queue/dax" 2>/dev/null)" = "1" && return 0 + return 1 } @@ -2194,15 +2204,18 @@ _require_dm_target() _require_sane_bdev_flush $SCRATCH_DEV _require_command "$DMSETUP_PROG" dmsetup - if __scratch_uses_fsdax; then - case $target in - stripe|linear|log-writes) - ;; - *) - _notrun "Cannot run tests with DAX on $target devices." - ;; - esac - fi + case $target in + stripe|linear|log-writes) + ;; + *) + if __scratch_uses_fsdax; then + _notrun "Cannot run tests with fsdax on $target devices." + fi + if __scratch_dev_has_dax; then + _notrun "Cannot use $target devices on DAX capable block devices." + fi + ;; + esac modprobe dm-$target >/dev/null 2>&1