From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH 3/8] generic/081: don't run on DAX capable devices
Date: Wed, 1 Jun 2022 19:03:26 -0700 [thread overview]
Message-ID: <YpgabpNTG0hC1zmF@magnolia> (raw)
In-Reply-To: <20220602003126.2903779-4-david@fromorbit.com>
On Thu, Jun 02, 2022 at 10:31:21AM +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>
Seems reasonable to me, who also sees weird problems on the dax vms...
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> ---
> 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
>
next prev parent reply other threads:[~2022-06-02 2:03 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 ` [PATCH 3/8] generic/081: don't run on DAX capable devices Dave Chinner
2022-06-02 2:03 ` Darrick J. Wong [this message]
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=YpgabpNTG0hC1zmF@magnolia \
--to=djwong@kernel.org \
--cc=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.