XFS Test Case:252 - Shows Wrong Output

[Allison Henderson]

On 06/22/2011 03:48 AM, Amit Sahrawat wrote:
> 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
>
> Please let me know about the vailidity of this result.

Hi there,

It looks like the "fpunch 4k 12k" is supposed to be what puts the hole 
there.  If I run the command you have above, the fiemap should show a 
hole like this:

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" 
somefile
wrote 8192/8192 bytes at offset 0
8 KiB, 2 ops; 0.0000 sec (217.014 MiB/sec and 55555.5556 ops/sec)
wrote 8192/8192 bytes at offset 12288
8 KiB, 2 ops; 0.0000 sec (339.674 MiB/sec and 86956.5217 ops/sec)
somefile:
  EXT: FILE-OFFSET      BLOCK-RANGE      TOTAL FLAGS
    0: [0..7]:          256..263             8   0x0
    1: [8..31]:         hole                24
    2: [32..39]:        288..295             8   0x1

If you do not see the hole, it could be your punch hole operation is 
failing for some reason.

Allison Henderson