All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: fstests@vger.kernel.org
Subject: [PATCH 3/8] generic/081: don't run on DAX capable devices
Date: Thu,  2 Jun 2022 10:31:21 +1000	[thread overview]
Message-ID: <20220602003126.2903779-4-david@fromorbit.com> (raw)
In-Reply-To: <20220602003126.2903779-1-david@fromorbit.com>

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>
---
 common/rc | 39 +++++++++++++++++++++++++++------------
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/common/rc b/common/rc
index 2f31ca46..c334cfbf 100644
--- a/common/rc
+++ b/common/rc
@@ -2116,21 +2116,33 @@ _require_sane_bdev_flush()
 # Decide if the scratch filesystem is likely to be mounted in fsdax mode.
 # It goes 3 ways based on mount options::
 #	1. "dax" or "dax=always" means always test using DAX
-#	2. "dax=never" means we'll never use DAX
+#	2. "dax=never" means we'll never use DAX.
 #	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.
+# Case 2 and 3 basically mean the same thing for the purpose of
+# _require_dm_target(). If the fs is not forcing the use of DAX, then DAX
+# can only be enabled if the underlying block device supports it.
+#
+# Returns 0 if the filesytem will use DAX, 1 if it won't.
 __scratch_uses_fsdax()
 {
 	local ops=$(_normalize_mount_options "$MOUNT_OPTIONS")
 
 	echo $ops | egrep -qw "dax(=always| |$)" && return 0
-	echo $ops | grep -qw "dax=never" && return 1
+	return 1
+}
 
+# Determine if the scratch device is DAX capable. Even 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
 }
 
@@ -2147,15 +2159,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
 
-- 
2.35.1


  parent reply	other threads:[~2022-06-02  0:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-02  0:31 fstests: new tests and various fixes Dave Chinner
2022-06-02  0:31 ` [PATCH 1/8] xfstests: Add Log Attribute Replay test Dave Chinner
2022-06-02  1:05   ` Darrick J. Wong
2022-06-03  1:41   ` [PATCH 1/8 v2] fstests: " Dave Chinner
2022-06-03  2:43     ` Darrick J. Wong
2022-06-03  4:55       ` Zorro Lang
2022-06-03  5:29         ` Dave Chinner
2022-06-02  0:31 ` [PATCH 2/8] README: document _begin_fstests better Dave Chinner
2022-06-02  0:51   ` Darrick J. Wong
2022-06-02  0:31 ` Dave Chinner [this message]
2022-06-02  2:03   ` [PATCH 3/8] generic/081: don't run on DAX capable devices Darrick J. Wong
2022-06-02  0:31 ` [PATCH 4/8] generic/038: kill background threads on interrupt Dave Chinner
2022-06-02  0:51   ` Darrick J. Wong
2022-06-02  0:31 ` [PATCH 5/8] xfs/538: fix fsstress scaling Dave Chinner
2022-06-02  0:52   ` Darrick J. Wong
2022-06-02  0:31 ` [PATCH 6/8] xfs/070: filter the bad sb magic number error Dave Chinner
2022-06-02  0:52   ` Darrick J. Wong
2022-06-02  0:31 ` [PATCH 7/8] xfs/167: adjust runtime with TIME_FACTOR Dave Chinner
2022-06-02  0:53   ` Darrick J. Wong
2022-06-02  0:31 ` [PATCH 8/8] xfs/189: systemd monitoring of /etc/fstab sucks Dave Chinner
2022-06-02  1:04   ` Darrick J. Wong
2022-06-03  1:54   ` [PATCH 8/8 v2] " Dave Chinner
2022-06-03  2:41     ` Darrick J. Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220602003126.2903779-4-david@fromorbit.com \
    --to=david@fromorbit.com \
    --cc=fstests@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.