From: Disha Goel <disgoel@linux.ibm.com>
To: "Nirjhar Roy (IBM)" <nirjhar.roy.lists@gmail.com>,
fstests@vger.kernel.org
Cc: linux-btrfs@vger.kernel.org, ritesh.list@gmail.com,
ojaswin@linux.ibm.com, djwong@kernel.org, zlang@kernel.org,
fdmanana@kernel.org, quwenruo.btrfs@gmx.com
Subject: Re: [PATCH v3 3/4] btrfs/137: Make this test compatible with all supported block sizes
Date: Fri, 22 Aug 2025 19:57:53 +0530 [thread overview]
Message-ID: <845a62e3-2c10-4fd8-9a62-ff01e5f921db@linux.ibm.com> (raw)
In-Reply-To: <88dcfb6cea422cebc5bbdcd4a0ba912f9c8666fa.1755677274.git.nirjhar.roy.lists@gmail.com>
On 20/08/25 1:45 pm, Nirjhar Roy (IBM) wrote:
> For large block sizes like 64k it failed simply because this
> test was written with 4k block size in mind.
> The first few lines of the error logs are as follows:
>
> d3dc847171f9081bd75d7a2d3b53d322 SCRATCH_MNT/snap2/bar
>
> File snap1/foo fiemap results in the original filesystem:
> -0: [0..7]: data
> +0: [0..127]: data
>
> File snap1/bar fiemap results in the original filesystem:
> ...
>
> Fix this by making the test choose offsets and block size as 64k
> which is aligned with all the underlying supported fs block sizes.
>
> Reviewed-by: Qu Wenruo <wqu@suse.com>
> Reported-by: Disha Goel <disgoel@linux.ibm.com>
> Signed-off-by: Nirjhar Roy (IBM) <nirjhar.roy.lists@gmail.com>
I tested it on Power, and the btrfs/137 test passes with both 4k & 64k
block sizes.
SECTION -- btrfs_64k
RECREATING -- btrfs on /dev/loop0
FSTYP -- btrfs
PLATFORM -- Linux/ppc64le localhost 6.17.0-rc2-00060-g068a56e56fa8
#3 SMP Thu Aug 21 17:54:04 IST 2025
MKFS_OPTIONS -- -f -s 65536 -n 65536 /dev/loop1
MOUNT_OPTIONS -- /dev/loop1 /mnt/scratch
btrfs/137 2s ... 1s
Ran: btrfs/137
Passed all 1 tests
Tested-by: Disha Goel <disgoel@linux.ibm.com>
> ---
> tests/btrfs/137 | 11 ++++----
> tests/btrfs/137.out | 66 ++++++++++++++++++++++-----------------------
> 2 files changed, 39 insertions(+), 38 deletions(-)
>
> diff --git a/tests/btrfs/137 b/tests/btrfs/137
> index 7710dc18..c1d498bd 100755
> --- a/tests/btrfs/137
> +++ b/tests/btrfs/137
> @@ -23,6 +23,7 @@ _cleanup()
> _require_test
> _require_scratch
> _require_xfs_io_command "fiemap"
> +_require_btrfs_no_compress
>
> send_files_dir=$TEST_DIR/btrfs-test-$seq
>
> @@ -33,12 +34,12 @@ _scratch_mkfs >>$seqres.full 2>&1
> _scratch_mount
>
> # Create the first test file.
> -$XFS_IO_PROG -f -c "pwrite -S 0xaa 0 4K" $SCRATCH_MNT/foo | _filter_xfs_io
> +$XFS_IO_PROG -f -c "pwrite -S 0xaa -b 64k 0 64K" $SCRATCH_MNT/foo | _filter_xfs_io
>
> # Create a second test file with a 1Mb hole.
> $XFS_IO_PROG -f \
> - -c "pwrite -S 0xaa 0 4K" \
> - -c "pwrite -S 0xbb 1028K 4K" \
> + -c "pwrite -S 0xaa -b 64k 0 64K" \
> + -c "pwrite -S 0xbb -b 64k 1088K 64K" \
> $SCRATCH_MNT/bar | _filter_xfs_io
>
> $BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT \
> @@ -46,10 +47,10 @@ $BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT \
>
> # Now add one new extent to our first test file, increasing its size and leaving
> # a 1Mb hole between the first extent and this new extent.
> -$XFS_IO_PROG -c "pwrite -S 0xbb 1028K 4K" $SCRATCH_MNT/foo | _filter_xfs_io
> +$XFS_IO_PROG -c "pwrite -S 0xbb -b 64k 1088K 64K" $SCRATCH_MNT/foo | _filter_xfs_io
>
> # Now overwrite the last extent of our second test file.
> -$XFS_IO_PROG -c "pwrite -S 0xcc 1028K 4K" $SCRATCH_MNT/bar | _filter_xfs_io
> +$XFS_IO_PROG -c "pwrite -S 0xcc -b 64k 1088K 64K" $SCRATCH_MNT/bar | _filter_xfs_io
>
> $BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT \
> $SCRATCH_MNT/snap2 >/dev/null
> diff --git a/tests/btrfs/137.out b/tests/btrfs/137.out
> index 8554399f..e863dd51 100644
> --- a/tests/btrfs/137.out
> +++ b/tests/btrfs/137.out
> @@ -1,63 +1,63 @@
> QA output created by 137
> -wrote 4096/4096 bytes at offset 0
> +wrote 65536/65536 bytes at offset 0
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 4096/4096 bytes at offset 0
> +wrote 65536/65536 bytes at offset 0
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 4096/4096 bytes at offset 1052672
> +wrote 65536/65536 bytes at offset 1114112
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 4096/4096 bytes at offset 1052672
> +wrote 65536/65536 bytes at offset 1114112
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -wrote 4096/4096 bytes at offset 1052672
> +wrote 65536/65536 bytes at offset 1114112
> XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>
> File digests in the original filesystem:
> -3e4309c7cc81f23d45e260a8f13ca860 SCRATCH_MNT/snap1/foo
> -f3934f0cf164e2efa1bab71f2f164990 SCRATCH_MNT/snap1/bar
> -f3934f0cf164e2efa1bab71f2f164990 SCRATCH_MNT/snap2/foo
> -d3dc847171f9081bd75d7a2d3b53d322 SCRATCH_MNT/snap2/bar
> +9802287a6faa01a1fd0e01732b732fca SCRATCH_MNT/snap1/foo
> +fe93f68ad1d8d5e47feba666ee6d3c47 SCRATCH_MNT/snap1/bar
> +fe93f68ad1d8d5e47feba666ee6d3c47 SCRATCH_MNT/snap2/foo
> +8d06f9b5841190b586a7526d0dd356f3 SCRATCH_MNT/snap2/bar
>
> File snap1/foo fiemap results in the original filesystem:
> -0: [0..7]: data
> +0: [0..127]: data
>
> File snap1/bar fiemap results in the original filesystem:
> -0: [0..7]: data
> -1: [8..2055]: hole
> -2: [2056..2063]: data
> +0: [0..127]: data
> +1: [128..2175]: hole
> +2: [2176..2303]: data
>
> File snap2/foo fiemap results in the original filesystem:
> -0: [0..7]: data
> -1: [8..2055]: hole
> -2: [2056..2063]: data
> +0: [0..127]: data
> +1: [128..2175]: hole
> +2: [2176..2303]: data
>
> File snap2/bar fiemap results in the original filesystem:
> -0: [0..7]: data
> -1: [8..2055]: hole
> -2: [2056..2063]: data
> +0: [0..127]: data
> +1: [128..2175]: hole
> +2: [2176..2303]: data
>
> At subvol SCRATCH_MNT/snap1
> At subvol SCRATCH_MNT/snap2
> At subvol snap1
>
> File digests in the new filesystem:
> -3e4309c7cc81f23d45e260a8f13ca860 SCRATCH_MNT/snap1/foo
> -f3934f0cf164e2efa1bab71f2f164990 SCRATCH_MNT/snap1/bar
> -f3934f0cf164e2efa1bab71f2f164990 SCRATCH_MNT/snap2/foo
> -d3dc847171f9081bd75d7a2d3b53d322 SCRATCH_MNT/snap2/bar
> +9802287a6faa01a1fd0e01732b732fca SCRATCH_MNT/snap1/foo
> +fe93f68ad1d8d5e47feba666ee6d3c47 SCRATCH_MNT/snap1/bar
> +fe93f68ad1d8d5e47feba666ee6d3c47 SCRATCH_MNT/snap2/foo
> +8d06f9b5841190b586a7526d0dd356f3 SCRATCH_MNT/snap2/bar
>
> File snap1/foo fiemap results in the new filesystem:
> -0: [0..7]: data
> +0: [0..127]: data
>
> File snap1/bar fiemap results in the new filesystem:
> -0: [0..7]: data
> -1: [8..2055]: hole
> -2: [2056..2063]: data
> +0: [0..127]: data
> +1: [128..2175]: hole
> +2: [2176..2303]: data
>
> File snap2/foo fiemap results in the new filesystem:
> -0: [0..7]: data
> -1: [8..2055]: hole
> -2: [2056..2063]: data
> +0: [0..127]: data
> +1: [128..2175]: hole
> +2: [2176..2303]: data
>
> File snap2/bar fiemap results in the new filesystem:
> -0: [0..7]: data
> -1: [8..2055]: hole
> -2: [2056..2063]: data
> +0: [0..127]: data
> +1: [128..2175]: hole
> +2: [2176..2303]: data
next prev parent reply other threads:[~2025-08-22 14:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-20 8:15 [PATCH v3 0/4] btrfs: Misc test fixes for large block/node sizes Nirjhar Roy (IBM)
2025-08-20 8:15 ` [PATCH v3 1/4] btrfs/301: Make the test compatible with all the supported block sizes Nirjhar Roy (IBM)
2025-08-22 14:19 ` Disha Goel
2025-08-20 8:15 ` [PATCH v3 2/4] generic/274: Make the pwrite block sizes and offsets to 64k Nirjhar Roy (IBM)
2025-08-22 14:25 ` Disha Goel
2025-08-25 4:34 ` Nirjhar Roy (IBM)
2025-08-25 4:44 ` Qu Wenruo
2025-08-25 6:07 ` Nirjhar Roy (IBM)
2025-08-20 8:15 ` [PATCH v3 3/4] btrfs/137: Make this test compatible with all supported block sizes Nirjhar Roy (IBM)
2025-08-22 14:27 ` Disha Goel [this message]
2025-08-20 8:15 ` [PATCH v3 4/4] generic/563: Increase the iosize to to cover for btrfs Nirjhar Roy (IBM)
2025-08-22 14:37 ` Disha Goel
2025-08-25 6:08 ` Nirjhar Roy (IBM)
2025-08-25 5:55 ` [PATCH v3 0/4] btrfs: Misc test fixes for large block/node sizes Ojaswin Mujoo
2025-08-25 6:08 ` Nirjhar Roy (IBM)
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=845a62e3-2c10-4fd8-9a62-ff01e5f921db@linux.ibm.com \
--to=disgoel@linux.ibm.com \
--cc=djwong@kernel.org \
--cc=fdmanana@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=nirjhar.roy.lists@gmail.com \
--cc=ojaswin@linux.ibm.com \
--cc=quwenruo.btrfs@gmx.com \
--cc=ritesh.list@gmail.com \
--cc=zlang@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).