Currently xfs/259 tests against TEST_DIR for CRC support status to
decide whether 512 block size should be tested, which is wrong for this
test, because configuration of TEST_DIR is not controlled by test
harness and can be different to the configuration being used in the
test.
Fix it by reversing the block size order that's tested and capture the
output of the actual mkfs command that is being tested, and determine if
512 byte block sizes should be tested based on that output.
While we're at it, I think the test matrix can be enlarged as well, 4k,
2k, 1k and 512 block size can be tested in each fs size boundary, not
only the minimum block size.
Suggested-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Test 259 tries to make a loop device size which is 1 byte less
than 4T; losetup now warns that this makes little sense, and
the warning breaks the test output:
+losetup: /mnt/test/259.image: warning: file does not fit into a 512-byte sector the end of the file will be ignored.
The RH QE testcase did originally use loopback, so did
not in effect test anything other than 512-multiple boundaries.
Just drop the non-512-byte-multiple cases, they produce
devices exactly the same size as their 512-byte-multiple
neighbors.
(FWIW, this is a regression test for the bug that
d943b11 mkfs: get size of device properly
fixed.)
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Rich Johnston <rjohnston@sgi.com>
Eryu Guan
Eric Sandeen
Dave Chinner