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@xxxxxxx>
---
.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@xxxxxxx - SGI
===============================================
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
