Re: XFS Test Case:252 - Shows Wrong Output

[Amit Sahrawat <amit.sahrawat83@xxxxxxxxx>]

This is the original result I got after running test case : 252

[root@localhost xfstests-2011-05-11]# ./check -xfs 252
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/i686 localhost 2.6.31.5-127.fc12.i686.PAE
MKFS_OPTIONS  -- -f -bsize=4096 /dev/sdb4
MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/sdb4 /media/d

252  - output mismatch (see 252.out.bad)
--- 252.out 2011-06-21 12:47:23.000000000 +0530
+++ 252.out.bad 2011-06-23 11:10:33.000000000 +0530
@@ -1,47 +1,51 @@
 QA output created by 252
  1. into a hole
+0: [0..7]: hole
+1: [8..23]: unwritten
+2: [24..39]: hole
  2. into allocated space
-0: [0..7]: data
-1: [8..23]: hole
-2: [24..39]: data
+0: [0..39]: data
  3. into unwritten space
-0: [0..7]: unwritten
-1: [8..23]: hole
-2: [24..39]: unwritten
+0: [0..39]: unwritten
  4. hole -> data
-0: [0..23]: hole
-1: [24..31]: data
-2: [32..39]: hole
+0: [0..7]: hole
+1: [8..15]: unwritten
+2: [16..31]: data
+3: [32..39]: hole
  5. hole -> unwritten
-0: [0..23]: hole
-1: [24..31]: unwritten
+0: [0..7]: hole
+1: [8..31]: unwritten
 2: [32..39]: hole
  6. data -> hole
-0: [0..7]: data
-1: [8..39]: hole
+0: [0..15]: data
+1: [16..23]: unwritten
+2: [24..39]: hole
  7. data -> unwritten
-0: [0..7]: data
-1: [8..23]: hole
-2: [24..31]: unwritten
-3: [32..39]: hole
+0: [0..15]: data
+1: [16..31]: unwritten
+2: [32..39]: hole
  8. unwritten -> hole
-0: [0..7]: unwritten
-1: [8..39]: hole
+0: [0..23]: unwritten
+1: [24..39]: hole
  9. unwritten -> data
-0: [0..7]: unwritten
-1: [8..23]: hole
-2: [24..31]: data
-3: [32..39]: hole
+0: [0..15]: unwritten
+1: [16..31]: data
+2: [32..39]: hole
  10. hole -> data -> hole
+0: [0..7]: hole
+1: [8..15]: unwritten
+2: [16..23]: data
+3: [24..31]: unwritten
+4: [32..39]: hole
  11. data -> hole -> data
-0: [0..7]: data
-1: [8..31]: hole
-2: [32..39]: data
+0: [0..15]: data
+1: [16..23]: unwritten
+2: [24..39]: data
  12. unwritten -> data -> unwritten
-0: [0..7]: unwritten
-1: [8..31]: hole
-2: [32..39]: unwritten
+0: [0..15]: unwritten
+1: [16..23]: data
+2: [24..39]: unwritten
  13. data -> unwritten -> data
-0: [0..7]: data
-1: [8..31]: hole
-2: [32..39]: data
+0: [0..15]: data
+1: [16..23]: unwritten
+2: [24..39]: data
Ran: 252
Failures: 252
Failed 1 of 1 tests
[root@localhost xfstests-2011-05-11]#

The above output if for kernel version 2.6.31..

 

Thanks & Regards,

Amit Sahrawat
 

On Thu, Jun 23, 2011 at 4:27 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:

On Wed, Jun 22, 2011 at 04:18:52PM +0530, Amit Sahrawat wrote:
> Dear All,
> **
> *Test Case:13
> *        echo "  13. data -> unwritten -> data"
>         rm -f $testfile
>         $XFS_IO_PROG $xfs_io_opt -f -c "truncate 20k" \
>                 -c "$alloc_cmd 0 20k" \
>                 -c "pwrite 0k 8k" -c "fsync" \
>                 -c "pwrite 12k 8k" -c "fsync" \
>                 -c "$zero_cmd 4k 12k" \
>                 -c "$map_cmd -v" $testfile | $filter_cmd
>         [ $? -ne 0 ] && die_now
>
> *After executing individual case like this:
> *testfile=/data/usb/sda3/252.testfile
>
> echo "13. data -> unwritten -> data"
> rm -f $testfile
> xfs_io -f -c "truncate 20k" -c \
> "falloc 0 20k" -c "pwrite 0k 8k" -c "fsync" -c "pwrite 12k 8k" -c  \
> "fsync" -c "fpunch 4k 12k" -c "fiemap -v" $testfile | $filter_cmd
>
> *Original Output(Taken from 252.out):
> *        13. data -> unwritten -> data
> 0: [0..7]: data
> 1: [8..31]: hole
> 2: [32..39]: data
> *Output in my case*
>   13. data -> unwritten -> data
> 0: [0..15]: data
> 1: [16..23]: unwritten
> 2: [24..39]: data

FWIW, it would be much easier for us to understand your problem if
you simply posted the output of a failing "check 252" (it's a diff
of the output vs the golden output!) rather than a bunch of strange
mangled script outputs from whatever wrapper you are using to run
xfstests that nobody but you understand.

Anyway, I'm pretty sure that 2.6.35.y doesn't support punching holes
via the fallocate operation and so this check in the test:

_require_xfs_io_falloc_punch

is probably not detecting that punch is not supported correctly.
Perhaps that is what you need to check first...

Cheers,

Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs