From: "Darrick J. Wong" <djwong@kernel.org>
To: djwong@kernel.org, guaneryu@gmail.com
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me
Subject: [PATCH 1/1] common/rc: re-fix detection of device-mapper/persistent memory incompatibility
Date: Wed, 15 Sep 2021 16:42:06 -0700 [thread overview]
Message-ID: <163174932597.379383.18426474248994143835.stgit@magnolia> (raw)
In-Reply-To: <163174932046.379383.10637812567210248503.stgit@magnolia>
From: Darrick J. Wong <djwong@kernel.org>
In commit e05491b3, I tried to resolve false test failures that were a
result of device mapper refusing to change access modes on a block
device that supports the FSDAX access mode. Unfortunately, I did not
realize that there are two ways that fsdax support can be detected via
sysfs: /sys/block/XXX/queue/dax and /sys/block/XXX/dax/, so I only added
a test for the latter.
As of 5.15-rc1 this doesn't seem to work anymore for some reason. I
don't know enough about the byzantine world of pmem device driver
initialization, but fsdax mode actually does work even though the
/sys/block/XXX/dax/ path went away. So clearly we have to detect it
via the other sysfs path.
Fixes: e05491b3 ("common/rc: fix detection of device-mapper/persistent memory incompatibility")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
common/rc | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/common/rc b/common/rc
index 154bc2dd..275b1f24 100644
--- a/common/rc
+++ b/common/rc
@@ -1964,6 +1964,20 @@ _require_sane_bdev_flush()
fi
}
+# Decide if the scratch filesystem is likely to be mounted in fsdax mode.
+# If there's a dax clause in the mount options we assume the test runner
+# wants us to test DAX; or if the scratch device itself advertises dax mode
+# in sysfs.
+__detect_scratch_fsdax()
+{
+ _normalize_mount_options | egrep -q "dax(=always| |$)" && return 0
+
+ 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
+}
+
# this test requires a specific device mapper target
_require_dm_target()
{
@@ -1975,9 +1989,7 @@ _require_dm_target()
_require_sane_bdev_flush $SCRATCH_DEV
_require_command "$DMSETUP_PROG" dmsetup
- _normalize_mount_options | egrep -q "dax(=always| |$)" || \
- test -e "/sys/block/$(_short_dev $SCRATCH_DEV)/dax"
- if [ $? -eq 0 ]; then
+ if __detect_scratch_fsdax; then
case $target in
stripe|linear|log-writes)
;;
next prev parent reply other threads:[~2021-09-15 23:42 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-15 23:42 [PATCHSET 0/1] fstests: random fixes Darrick J. Wong
2021-09-15 23:42 ` Darrick J. Wong [this message]
2021-09-16 7:46 ` [PATCH 1/1] common/rc: re-fix detection of device-mapper/persistent memory incompatibility Christoph Hellwig
2021-09-17 0:48 ` [PATCH 2/1] common/rc: use directio mode for the loop device when possible Darrick J. Wong
2021-09-17 20:14 ` riteshh
2021-09-18 0:49 ` 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=163174932597.379383.18426474248994143835.stgit@magnolia \
--to=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=guan@eryu.me \
--cc=guaneryu@gmail.com \
--cc=linux-xfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).