All of lore.kernel.org
 help / color / mirror / Atom feed
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 1/4] btrfs/301: Make the test compatible with all the supported block sizes
Date: Fri, 22 Aug 2025 19:49:00 +0530	[thread overview]
Message-ID: <fcc241b7-2323-4375-9ce2-40eada4966f8@linux.ibm.com> (raw)
In-Reply-To: <83e91ed9d2b55bdf6e63f9607267d36e31548f07.1755677274.git.nirjhar.roy.lists@gmail.com>

On 20/08/25 1:45 pm, Nirjhar Roy (IBM) wrote:
> With large block sizes like 64k the test failed with the
> following logs:
> 
>       QA output created by 301
>       basic accounting
>      +subvol 256 mismatched usage 33947648 vs 4587520 (expected data 4194304 expected meta 393216 diff 29360128)
>      +subvol 256 mismatched usage 168165376 vs 138805248 (expected data 138412032 expected meta 393216 diff 29360128)
>      +subvol 256 mismatched usage 33947648 vs 4587520 (expected data 4194304 expected meta 393216 diff 29360128)
>      +subvol 256 mismatched usage 33947648 vs 4587520 (expected data 4194304 expected meta 393216 diff 29360128)
>       fallocate: Disk quota exceeded
> 
> The test creates nr_fill files each of size 8k. Now with 64k
> block size, 8k sized files occupy more than the expected sizes (i.e, 8k)
> due to internal fragmentation, since 1 file will occupy at least 1
> fsblock. Fix this by making the file size 64k, which is aligned
> with all the supported 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/301 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/301 67s ...  111s
Ran: btrfs/301
Passed all 1 tests

Tested-by: Disha Goel <disgoel@linux.ibm.com>

> ---
>   tests/btrfs/301 | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/btrfs/301 b/tests/btrfs/301
> index 6b59749d..be346f52 100755
> --- a/tests/btrfs/301
> +++ b/tests/btrfs/301
> @@ -23,7 +23,7 @@ subv=$SCRATCH_MNT/subv
>   nested=$SCRATCH_MNT/subv/nested
>   snap=$SCRATCH_MNT/snap
>   nr_fill=512
> -fill_sz=$((8 * 1024))
> +fill_sz=$((64 * 1024))
>   total_fill=$(($nr_fill * $fill_sz))
>   nodesize=$($BTRFS_UTIL_PROG inspect-internal dump-super $SCRATCH_DEV | \
>   					grep nodesize | $AWK_PROG '{print $2}')


  reply	other threads:[~2025-08-22 14:19 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 [this message]
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
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=fcc241b7-2323-4375-9ce2-40eada4966f8@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 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.