All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.