xfstests: generic/255: Execute only if blocksize <= 4096

The patch adds the function _require_le_4k_blocksize to perform the block size check on $TEST_DEV and $SCRATCH_DEV.

---
 common/rc         | 10 ++++++++++
 tests/generic/255 |  1 +
 2 files changed, 11 insertions(+)

index ae80b12..d8ee132 100644
@@ -2106,6 +2106,16 @@ _require_dumpe2fs()
 	fi
 }
 
+_require_le_4k_blocksize()
+{
+	test_dev_bs=`stat -f $TEST_DEV | grep "Block size" | cut -d " " -f3`
+	scratch_dev_bs=`stat -f $SCRATCH_DEV | grep "Block size" | cut -d " " -f3`
+
+	if (( $test_dev_bs > 4096 || $scratch_dev_bs > 4096 )); then
+		_notrun "This test requires a filesystem with a block size less than or equal to 4k."
+	fi
+}
+
 _create_loop_device()
 {
 	file=$1

index dd329b4..763e861 100755
@@ -49,6 +49,7 @@ _supported_os Linux
 _require_xfs_io_falloc_punch
 _require_xfs_io_falloc
 _require_xfs_io_fiemap
+_require_le_4k_blocksize
 
 testfile=$TEST_DIR/255.$$
 

1.8.3.1

Can you explain why this is necessary?

What failures do you see, on what filesystems?

That kind of info needs to be in the changelog so reviewers can understand the need for the change (and to be sure it's not papering over an actual bug for block sizes

Thanks,
-Eric

generic/255 currently fails on Btrfs on a ppc64 machine with 64k page size and hence 64k block size.

generic/255 has been written to test the corner cases for 4k block size. I did try to make it work with variable sized block sizes, But I got stuck working with md5sum (since we would need two sets of md5sums, due to _test_generic_punch() being invoked with and without '-k' option per block size).

Since 4k block size support for Btrfs on ppc64 is already being worked on, I think its better to prevent execution of generic/255 for block sizes greater than 4k.

Apologies for not including the above description in the patch.

- chandan

It happens. ;)

To be honest I haven't really looked at how _test_generic_punch & generic/255 works lately.

Just as a sanity check, does it also fail on xfs for 64k block sizes on ppc64?

Thanks,
-Eric

Yes, it does fail as shown below:

generic/255 - output mismatch (see /home/chandan/xfstests/results//generic/255.out.bad)

    --- tests/generic/255.out   2013-08-27 06:59:08.241344176 -0400
    +++ /home/chandan/xfstests/results//generic/255.out.bad     2013-08-27 07:01:45.311352161 -0400
    @@ -2,306 +2,202 @@
        1. into a hole
     daa100df6e6711906b61c9ab5aa16032
        2. into allocated space
    -0: [0..7]: extent
    -1: [8..23]: hole
    -2: [24..39]: extent
    +0: [0..127]: extent
     ...
     (Run 'diff -u tests/generic/255.out /home/chandan/xfstests/results//generic/255.out.bad' to see the entire diff)

In this instance, the test basically ends up punching a hole within a block and hence fails.

- chandan

(removing linux-btrfs for now):

Hohum, I get failures on 2k and even 4k blocksize xfs (and ext4) on ppc64 as well. (this was on a 3.10 kernel)

Have you seen this?

I guess I'm a little reluctant to restrict the test to <=4k until we understand what all the issues are and at least see it passing on the smaller block sizes... do they work for you?

-Eric

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

Eric,

I have posted a patch that fixes _test_generic_punch() to obtain the correct block size. With that patch applied, the code works for 4k blocksize for both xfs and ext4.

Even the with the above mentioned fix applied, the code doesn't work with block sizes != 4k. The extent ranges in 255.out were obtained for 4k block sizes and hence they don't work for other block sizes. I will repost the patch to restrict execution of generic/255 only when the block size is 4k.

- chandan

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs