[PATCH 2/3] xfs/185: don't fail when rtfile is larger than rblocks

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



From: Darrick J. Wong <djwong@xxxxxxxxxx>

This test creates a 200MB rt volume on a file-backed loopdev.  However,
if the size of the loop file is not congruent with the rt extent size
(e.g.  28k) then the rt volume will not use all 200MB because we cannot
have partial rt extents.  Because of this rounding, we can end up with
an fsmap listing that covers fewer sectors than the bmap of the loop
file.

Fix the test to allow this case.

Cc: <fstests@xxxxxxxxxxxxxxx> # v2022.05.01
Fixes: 410a2e3186a1e8 ("xfs: regresion test for fsmap problems with realtime")
Signed-off-by: Darrick J. Wong <djwong@xxxxxxxxxx>
---
 tests/xfs/185 |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)


diff --git a/tests/xfs/185 b/tests/xfs/185
index b14bcb9b791bb8..f3601a5292ef0b 100755
--- a/tests/xfs/185
+++ b/tests/xfs/185
@@ -156,7 +156,9 @@ fsmap() {
 
 # Check the fsmap output contains a record for the realtime device at a
 # physical offset higher than end of the data device and corresponding to the
-# beginning of the non-punched area.
+# beginning of the non-punched area.  The "found_end" check uses >= because
+# rtfile can be larger than the number of rtextents if the size of the rtfile
+# is not congruent with the rt extent size.
 fsmap | $AWK_PROG -v dev="$rtmajor:$rtminor" -v offset=$expected_offset -v end=$expected_end '
 BEGIN {
 	found_start = 0;
@@ -165,7 +167,7 @@ BEGIN {
 {
 	if ($1 == dev && $2 >= offset) {
 		found_start = 1;
-		if ($3 == end) {
+		if ($3 >= end) {
 			found_end = 1;
 		}
 	}





[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux