public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michael L. Semon" <mlsemon35@gmail.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: oops from deliberate block trashing (of course!)
Date: Thu, 28 Mar 2013 02:43:35 -0400	[thread overview]
Message-ID: <5153E697.7060800@gmail.com> (raw)
In-Reply-To: <20130328061415.GF6369@dastard>

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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-03-28  6:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-28  5:18 oops from deliberate block trashing (of course!) Michael L. Semon
2013-03-28  6:14 ` Dave Chinner
2013-03-28  6:43   ` Michael L. Semon [this message]
2013-03-28 15:44 ` Ben Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5153E697.7060800@gmail.com \
    --to=mlsemon35@gmail.com \
    --cc=david@fromorbit.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox