xfs
[Top] [All Lists]

Re: oops from deliberate block trashing (of course!)

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: oops from deliberate block trashing (of course!)
From: "Michael L. Semon" <mlsemon35@xxxxxxxxx>
Date: Thu, 28 Mar 2013 02:43:35 -0400
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XFMhQskc1pCkNJAgetaxjDz2GomAl9tGX1KIK3Udfak=; b=jrNPME8ympAJy/GHSDhUvE0sDOEvMDMiKqIaQQha/jfKG8iPxfCcLIOfDcmuCxVBMZ iIrSSqQCHLL7fCHMgDara+DrF1pLfzzHWqmHNdsv8nnuU7J8JRBIHFi2KPAF0gO0IaNY sCyYVYbruYxh/PAN5IKXUHQ6evQVDb7ykPXTwNR7wjdtFMKdUcKUAJ6/w0g3/yVL7QPr Flm2cSSSw5yyPpyz3Q9MYu4qMAiOGYMvVYNWH0cQFP+PYvxiSMKrYbgIXQYhnLHI/fH9 /7oAJxm8G7kzaXVNAQKCJBj1/jUdPbU4XJGvqX9gPPk2t5WsdsOcgbORlWSJKk3y2+Tf o28A==
In-reply-to: <20130328061415.GF6369@dastard>
References: <CAJzLF9nPt9aOrH+Dj12b5os74XT8ke9g4G=DA9xgR0AyehvaBA@xxxxxxxxxxxxxx> <20130328061415.GF6369@dastard>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
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

<Prev in Thread] Current Thread [Next in Thread>