Newer fstrim(1) reports trimmed bytes differently, e.g.
new fstrim: /mnt/ext4: 9.7 GiB (10411118592 bytes) trimmed
old fstrim: /mnt/ext4: 10411118592 bytes were trimmed
generic/260 reports syntax error
+./tests/generic/260: line 111: [: 9.7: integer expression expected
+./tests/generic/260: line 121: [: 9.7: integer expression expected
+./tests/generic/260: line 183: [: 9.7: integer expression expected
Fix it so 260 passes with both old and new fstrim.
Signed-off-by: Eryu Guan <eguan@xxxxxxxxxx>
---
tests/generic/260 | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/tests/generic/260 b/tests/generic/260
index dc8b822..bc9eb3b 100755
--- a/tests/generic/260
+++ b/tests/generic/260
@@ -104,9 +104,8 @@ _scratch_mount
# This is a bit fuzzy, but since the file system is fresh
# there should be at least (fssize/2) free space to trim.
# This is supposed to catch wrong FITRIM argument handling
-out=$($FSTRIM_PROG -v -o10M $SCRATCH_MNT)
-nopref=${out##*: }
-bytes=${nopref%% *}
+out=$($FSTRIM_PROG -v -o10M $SCRATCH_MNT | egrep -o "[0-9]+ bytes")
+bytes=${out%% *}
if [ $bytes -gt $(_math "$fssize*1024") ]; then
status=1
@@ -177,9 +176,8 @@ _scratch_mount
# It is because btrfs does not have not-yet-used parts of the device
# mapped and since we got here right after the mkfs, there is not
# enough free extents in the root tree.
-out=$($FSTRIM_PROG -v -l$len $SCRATCH_MNT)
-nopref=${out##*: }
-bytes=${nopref%% *}
+out=$($FSTRIM_PROG -v -l$len $SCRATCH_MNT | egrep -o "[0-9]+ bytes")
+bytes=${out%% *}
if [ $bytes -le $(_math "$fssize*512") ] && [ $FSTYP != "btrfs" ]; then
status=1
echo "It seems that fs logic handling len argument overflows"
--
1.8.3.1
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
