Thread (17 messages) 17 messages, 1 author, 2018-09-06
STALE2867d
Revisions (5)
  1. v1 [diff vs current]
  2. v2 current
  3. v3 [diff vs current]
  4. v4 [diff vs current]
  5. v5 [diff vs current]

[PATCH V2 12/16] Fix generic/172 to work with 64k block size

From: Chandan Rajendra <hidden>
Date: 2018-09-06 13:13:11
Also in: linux-xfs
Subsystem: the rest · Maintainer: Linus Torvalds

For 64k block size, With 256MiB as the XFS filesystem size and 168 MiB
as the size of the clone source file, we end up hitting ENOSPC when
cloning the source file. This happens due to lack of space for housing
the corresponding metadata. This scenario also occurs when using a
512MiB XFS filesystem and 300MiB clone source file.

Hence this commit increases the size of the test filesystem to 1 GiB and
the size of the clone source file to 768MiB.

Signed-off-by: Chandan Rajendra <redacted>
---
 tests/generic/172 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/generic/172 b/tests/generic/172
index 5d6f295..08d2789 100755
--- a/tests/generic/172
+++ b/tests/generic/172
@@ -47,8 +47,8 @@ echo "Reformat with appropriate size"
 blksz="$(_get_block_size $testdir)"
 umount $SCRATCH_MNT
 
-file_size=$((168 * 1024 * 1024))
-fs_size=$((256 * 1024 * 1024))
+file_size=$((768 * 1024 * 1024))
+fs_size=$((1024 * 1024 * 1024))
 _scratch_mkfs_sized $fs_size >> $seqres.full 2>&1
 _scratch_mount >> $seqres.full 2>&1
 rm -rf $testdir
-- 
2.9.5
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help