Re: [PATCH 1/1] xfstest: using extsize cause corruption with multi buffer page

[Alain Renaud <arenaud@sgi.com>]

Hi Dave,

The reason I did it the way I did is because if I do not do the unmount it 
can take 5 to 10 iteration to reproduce the problem. However your version 
with xfs_io is much simpler I will
update the code with your change.

Second for the stale data if you look at buffer 3(11) and 4(12) you see 
that xfs_bmap show the buffer as REAL but they should be unwritten so what 
you read is what ever is on disk at the time (aka stale data).

The kernel I used for the testing is  3.4.0-rc2-0.2-default+ it is from 
oss.sgi.com and the branch head is

14c26c6a05de138a4fd9a0c05ff8e7435a618324 xfs: add trace points for log forces
3ba316037470bbf98c8a16c2179c02794fb8862e xfs: fix memory reclaim deadlock 
on agi buffer
ea562ed6e7df5acd9392d993882c39e855099165 xfs: fix delalloc quota accounting 
on failure


Again thanks a lot for the feedback I will provide an updated test with 
your suggested change.




On 12-06-05 05:13 AM, Dave Chinner wrote:
> On Fri, Jun 01, 2012 at 02:58:16PM -0400, Alain Renaud wrote:
>>    Test using extsize to create a file with multiple extent in one
>> PAGE. This show an error in the block conversion from unwritten
>> to real. As a result we tag raw disk block as valid(3-4) and
>> valid data as unwritten(5-6)
>>
>> On an x86_64 machine the page should look like this.
>>
>> buffer  content
>> 0       empty  b_state = 0
>> 1       DATA   b_state = 0x1023
>> 2       DATA   b_state = 0x1023
>> 3       empty  b_state = 0
>> 4       empty  b_state = 0
>> 5       DATA   b_state = 0x1023
>> 6       DATA   b_state = 0x1023
>> 7       empty  b_state = 0
>>
>> Signed-off-by: Alain Renaud<arenaud@sgi.com>
>>
>> ---
>>   .gitignore         |    1 	1 +	0 -	0 !
>>   287                |   74 	74 +	0 -	0 !
>>   287.out            |    1 	1 +	0 -	0 !
>>   group              |    1 	1 +	0 -	0 !
>>   src/Makefile       |    2 	1 +	1 -	0 !
>>   src/extsize_page.c |  113 	113 +	0 -	0 !
>>   6 files changed, 191 insertions(+), 1 deletion(-)
>>   create mode 100755 287
>>   create mode 100644 287.out
>>   create mode 100644 src/extsize_page.c
> .....
>
> Far too verbose - xfs_io can do just about everything for you in 5
> lines.  And you don't need a template file to compare to - just dump
> the hexdump output in the to golden image and the test harness will
> do the comapre for you.
>
> Also, see test 194 for the way we normally set up such a test:
>
> pgsize=`$here/src/feature -s`
> blksize=`expr $pgsize / 8`
> ....
> _scratch_mkfs_xfs -b size=$blksize>/dev/null 2>&1
>
> and the core of the xfs_io based test is:
>
> mnt=/mnt/scratch
> test_file=$mnt/foo
>
> rm -f $test_file
> xfs_io -f -c "extsize `expr $pgsize \* 10`" \
>          -c "pwrite `expr $pgsize + $blksize` `expr $blksize \* 2`" \
>          -c "pwrite `expr $pgsize + $blksize \* 5` `expr $blksize \* 2`" \
>          -c "truncate `expr $pgsize \* 3`" \
>          -c stat -c "bmap -vp" \
>          $test_file
> hexdump $test_file
>
> umount $mnt
> mount $mnt
>
> hexdump $test_file
>
> --
>
> The output I get on a current 3.5-rc1 kernel is this:
>
> wrote 1024/1024 bytes at offset 4608
> 1 KiB, 2 ops; 0.0000 sec (15.751 MiB/sec and 32258.0645 ops/sec)
> wrote 1024/1024 bytes at offset 6656
> 1 KiB, 2 ops; 0.0000 sec (97.656 MiB/sec and 200000.0000 ops/sec)
> fd.path = "/mnt/scratch/foo"
> fd.flags = non-sync,non-direct,read-write
> stat.ino = 35
> stat.type = regular file
> stat.size = 12288
> stat.blocks = 80
> fsxattr.xflags = 0x800 [----------e---]
> fsxattr.projid = 0
> fsxattr.extsize = 40960
> fsxattr.nextents = 3
> fsxattr.naextents = 0
> dioattr.mem = 0x200
> dioattr.miniosz = 512
> dioattr.maxiosz = 2147483136
> /mnt/scratch/foo:
>   EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL FLAGS
>     0: [0..8]:          48..56            0 (48..56)             9 10000
>     1: [9..12]:         57..60            0 (57..60)             4 00000
>     2: [13..79]:        61..127           0 (61..127)           67 10000
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0001200 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd
> *
> 0001600 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0001a00 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd
> *
> 0001e00 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0003000
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0001200 cdcd cdcd cdcd cdcd cdcd cdcd cdcd cdcd
> *
> 0001600 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0003000
>
>
> Which shows that the second region wasn't converted. I'm not sure
> why you are seeing stale data - you should see zeros because the
> region is still unwritten. What kernel are you testing on?
>
>
>

-- 
===============================================
Alain Renaud     - Cluster File System Engineer
arenaud@sgi.com  - SGI
===============================================

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