From: Nirjhar Roy (IBM) Date: Tue, 16 Sep 2025 15:30:09 +0000 (+0000) Subject: generic/371: Fix the test to be compatible block sizes upto 64k X-Git-Tag: v2026.01.27~5 X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=725b08a6d61ad5f860198f8c67e09d34b9563954;p=xfstests-dev.git generic/371: Fix the test to be compatible block sizes upto 64k When this test was ran with btrfs with 64k sector/block size, it failed with QA output created by 371 Silence is golden +fallocate: No space left on device +pwrite: No space left on device +fallocate: No space left on device +pwrite: No space left on device +pwrite: No space left on device ... This is what is going on: Let us see the following set of operations: --- With 4k sector size --- $ mkfs.btrfs -f -b 256m -s 4k -n 4k /dev/loop0 $ mount /dev/loop0 /mnt1/scratch/ $ df -h /dev/loop0 Filesystem Size Used Avail Use% Mounted on /dev/loop0 256M 1.5M 175M 1% /mnt1/scratch $ xfs_io -f -c "pwrite 0 80M" /mnt1/scratch/t1 wrote 83886080/83886080 bytes at offset 0 80 MiB, 20480 ops; 0.4378 sec (182.693 MiB/sec and 46769.3095 ops/sec) $ df -h /dev/loop0 Filesystem Size Used Avail Use% Mounted on /dev/loop0 256M 1.5M 175M 1% /mnt1/scratch $ sync $ df -h /dev/loop0 Filesystem Size Used Avail Use% Mounted on /dev/loop0 256M 82M 95M 47% /mnt1/scratch $ xfs_io -f -c "pwrite 0 80M" /mnt1/scratch/t2 wrote 83886080/83886080 bytes at offset 0 80 MiB, 20480 ops; 0:00:01.25 (63.881 MiB/sec and 16353.4648 ops/sec) $ df -h /dev/loop0 Filesystem Size Used Avail Use% Mounted on /dev/loop0 256M 137M 40M 78% /mnt1/scratch $ sync $ df -h /dev/loop0 Filesystem Size Used Avail Use% Mounted on /dev/loop0 256M 162M 15M 92% /mnt1/scratch Now let us repeat with 64k sector size --- With 64k sector size --- $ mkfs.btrfs -f -b 256m -s 64k -n 64k /dev/loop0 $ mount /dev/loop0 /mnt1/scratch/ $ df -h /dev/loop0 Filesystem Size Used Avail Use% Mounted on /dev/loop0 256M 24M 175M 12% /mnt1/scratch $ xfs_io -f -c "pwrite 0 80M" /mnt1/scratch/t1 wrote 83886080/83886080 bytes at offset 0 80 MiB, 20480 ops; 0.8460 sec (94.553 MiB/sec and 24205.4914 ops/sec) $ $ df -h /dev/loop0 Filesystem Size Used Avail Use% Mounted on /dev/loop0 256M 24M 175M 12% /mnt1/scratch $ sync $ df -h /dev/loop0 Filesystem Size Used Avail Use% Mounted on /dev/loop0 256M 104M 95M 53% /mnt1/scratch $ xfs_io -f -c "pwrite 0 80M" /mnt1/scratch/t2 pwrite: No space left on device Now, we can see that with 64k node size, 256M is not sufficient to hold 2 files worth 80M. For 64k, we can also see that the initial space usage on a fresh filesystem is 24M and for 4k its 1.5M. So because of higher node size, more metadata space is getting used. This test requires the size of the filesystem to be at least capable to hold 2 80M files. Fix this by increasing the fs size from 256M to 330M. Reported-by: Disha Goel Signed-off-by: Nirjhar Roy (IBM) Reviewed-by: Zorro Lang Signed-off-by: Zorro Lang --- diff --git a/tests/generic/371 b/tests/generic/371 index b312c450..95af308e 100755 --- a/tests/generic/371 +++ b/tests/generic/371 @@ -19,7 +19,7 @@ _require_scratch _require_xfs_io_command "falloc" test "$FSTYP" = "xfs" && _require_xfs_io_command "extsize" -_scratch_mkfs_sized $((256 * 1024 * 1024)) >> $seqres.full 2>&1 +_scratch_mkfs_sized $((330 * 1024 * 1024)) >> $seqres.full 2>&1 _scratch_mount # Disable speculative post-EOF preallocation on XFS, which can grow fast enough