From: Neal Gompa <neal@gompa.dev>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org,
Hector Martin <marcan@marcan.st>
Subject: Re: [PATCH] btrfs/246: skip the test if the tested btrfs doesn't support inline extents creation
Date: Wed, 22 Mar 2023 08:14:06 -0400 [thread overview]
Message-ID: <CAEg-Je-D9VR7G_kcr0u6CUqaGETsgDmr7xLvB348k-nMqdfjvQ@mail.gmail.com> (raw)
In-Reply-To: <dc3eb7e8a9286b2eab1fd1829e56428300d51a5a.1679464212.git.wqu@suse.com>
On Wed, Mar 22, 2023 at 1:59 AM Qu Wenruo <wqu@suse.com> wrote:
>
> [FALSE ALERT]
> If test case btrfs/246 is executed with a 16K page sized system (like
> some aarch64 SoCs) using 4K sector size (would be the new default), the
> test case would fail with output mismatch:
>
> btrfs/246 1s ... - output mismatch (see ~/xfstests-dev/results//btrfs/246.out.bad)
> --- tests/btrfs/246.out 2022-11-24 19:53:53.158470844 +0800
> +++ ~/xfstests-dev/results//btrfs/246.out.bad 2023-03-22 13:27:34.975796048 +0800
> @@ -3,3 +3,5 @@
> 0ca3bfdeda1ef5036bfa5dad078a9f15724e79cf296bd4388cf786bfaf4195d0 SCRATCH_MNT/foobar
> sha256sum after mount cycle
> 0ca3bfdeda1ef5036bfa5dad078a9f15724e79cf296bd4388cf786bfaf4195d0 SCRATCH_MNT/foobar
> +no inline extent found
> +no compressed extent found
> ...
> (Run 'diff -u ~/xfstests-dev/tests/btrfs/246.out ~/xfstests-dev/results//btrfs/246.out.bad' to see the entire diff)
>
> [CAUSE]
> For current btrfs subpage support, there are still some limitations:
>
> - No compressed write if the range is not fully page aligned
> - No inline extents creation
> Reading inline extents is still supported
>
> Thus we won't create such inlined compressed extent at all.
>
> [FIX]
> Just skip the test case if we can not even create a regular inline
> extent.
>
> This is done by a new require helper,
> _require_btrfs_inline_extent_creation(), which would detect if btrfs can
> even create an uncompressed inlined extent.
>
> Reported-by: Hector Martin <marcan@marcan.st>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
> common/btrfs | 22 ++++++++++++++++++++++
> tests/btrfs/246 | 3 +++
> 2 files changed, 25 insertions(+)
>
> diff --git a/common/btrfs b/common/btrfs
> index 7c32360376c2..344509ce300c 100644
> --- a/common/btrfs
> +++ b/common/btrfs
> @@ -499,6 +499,28 @@ _require_btrfs_support_sectorsize()
> _notrun "sectorsize $sectorsize is not supported"
> }
>
> +_require_btrfs_inline_extents_creation()
> +{
> + local ino
> +
> + _require_xfs_io_command fiemap
> + _require_scratch
> +
> + _scratch_mkfs &> /dev/null
> + _scratch_mount -o max_inline=2048,compress=none
> + _pwrite_byte 0x00 0 1024 $SCRATCH_MNT/inline &> /dev/null
> + sync
> + $XFS_IO_PROG -c "fiemap -v" $SCRATCH_MNT/inline | tail -n 1 > $tmp.fiemap
> + _scratch_unmount
> + # 0x200 means inlined, 0x100 means not block aligned, 0x1 means
> + # the last extent.
> + if ! grep -q "0x301" $tmp.fiemap; then
> + rm -f -- $tmp.fiemap
> + _notrun "No inline extent creation support, maybe subpage?"
> + fi
> + rm -f -- $tmp.fiemap
> +}
> +
> _btrfs_metadump()
> {
> local device="$1"
> diff --git a/tests/btrfs/246 b/tests/btrfs/246
> index 0dcc7c0d1a43..2fe54f959048 100755
> --- a/tests/btrfs/246
> +++ b/tests/btrfs/246
> @@ -23,6 +23,9 @@ _cleanup()
> _supported_fs btrfs
> _require_scratch
>
> +# If it's subpage case, we don't support inline extents creation for now.
> +_require_btrfs_inline_extents_creation
> +
> _scratch_mkfs > /dev/null
> _scratch_mount -o compress,max_inline=2048
>
> --
> 2.39.2
>
LGTM.
Reviewed-by: Neal Gompa <neal@gompa.dev>
--
真実はいつも一つ!/ Always, there's only one truth!
prev parent reply other threads:[~2023-03-22 12:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-22 5:52 [PATCH] btrfs/246: skip the test if the tested btrfs doesn't support inline extents creation Qu Wenruo
2023-03-22 12:14 ` Neal Gompa [this message]
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=CAEg-Je-D9VR7G_kcr0u6CUqaGETsgDmr7xLvB348k-nMqdfjvQ@mail.gmail.com \
--to=neal@gompa.dev \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=wqu@suse.com \
/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.