On 03/28/2013 02:14 AM, Dave Chinner wrote:
On Thu, Mar 28, 2013 at 01:18:24AM -0400, Michael L. Semon wrote:
==== SECOND OOPS: xfs_db blocktrash test
root@oldsvrhw:~# xfs_db -x /dev/sdb2
xfs_db> blockget
xfs_db> blocktrash -n 10240 -s 755366564 -3 -x 1 -y 16
blocktrash: 0/17856 inode block 6 bits starting 423:0 randomized
[lots of blocktrash stuff removed but still available]
blocktrash: 3/25387 dir block 2 bits starting 1999:1 randomized
xfs_db> quit
root@oldsvrhw:~# mount /dev/sdb2 /mnt/hole-test/
root@oldsvrhw:~# cd /mnt/hole-test/
root@oldsvrhw:/mnt/hole-test# find . -type f
XFS (sdb2): Mounting Filesystem
XFS (sdb2): Ending clean mount
XFS (sdb2): Invalid inode number 0x40000000800084
XFS (sdb2): Internal error xfs_dir_ino_validate at line 160 of file
fs/xfs/xfs_dir2.c. Caller 0xc12b9d0d
Pid: 97, comm: kworker/0:1H Not tainted 3.9.0-rc1+ #1
Call Trace:
[<c1270cbb>] xfs_error_report+0x4b/0x50
[<c12b9d0d>] ? __xfs_dir3_data_check+0x3cd/0x710
[<c12b6326>] xfs_dir_ino_validate+0xb6/0x180
[<c12b9d0d>] ? __xfs_dir3_data_check+0x3cd/0x710
[<c12b9d0d>] __xfs_dir3_data_check+0x3cd/0x710
[<c105ffe8>] ? update_curr.constprop.41+0xa8/0x180
[<c12b7289>] xfs_dir3_block_verify+0x89/0xa0
And here we validating a different directory block, and finding that
the inode number it points to is invalid. So, same thing - debug
kernel fires an assert, production kernel returns EFSCORRUPTED.
What you are seeing is that the verifiers are doing their job as
intended - catching corruption that is on disk as soon as we
possibly can. i.e. before it has the chance of being propagated
further.
Cheers,
Dave.
Very good! It's good to learn that all of those verifiers are doing
their jobs...that the ASSERTs all have some kind of dedicated
purpose...and that I shouldn't face this in non-debug mode.
These proof-positve crash reports are excellent. I just wish I knew how
to make them on purpose.
Thanks again, Dave.
Michael
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
