linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: linux-ext4@vger.kernel.org
Subject: Re: Weird filesystem corruption from wayland / radeon / chromium
Date: Tue, 13 Nov 2012 16:13:31 -0600	[thread overview]
Message-ID: <50A2C60B.1040405@redhat.com> (raw)
In-Reply-To: <50A29161.4060506@redhat.com>

On 11/13/12 12:28 PM, Eric Sandeen wrote:
> On 11/2/12 1:55 PM, Tim Landscheidt wrote:

...

>>> What does
>>
>>> # debugfs -R "dump_extents <274258>" /dev/dm-4
>>
>>> show? (or whatever the appropriate device node path is)
>>
>> See attachment.
> 
> Level Entries       Logical          Physical Length Flags
>  0/ 1   1/  2     0 -  3665 1114157             3666
>  1/ 1   1/ 59     0 -   132  510721 -  510853    133 
>  1/ 1   2/ 59   133 -   139  511415 -  511421      7 
> ...
>  1/ 1  58/ 59  3039 -  3664  573440 -  574065    626 
>  1/ 1  59/ 59  3665 -  4092  574066 -  574493    428 
>  0/ 1   2/  2  3666 -  9217  395702             5552
>  1/ 1   1/307  4093 -  4093  574494 -  574494      1 
>  1/ 1   2/307  4094 -  4095  395758 -  395759      2 
> ...
> 
> Ok, so the first top-level record says it covers logical 0->3665,
> but the last extent actually goes from 3665->4092.
> 
> Then the next top level extent says it covers 3666->9217,
> but that overlaps w/ the last real extent just prior, and
> the first allocated extent under it actually starts at 4093.
> 
> so,
> a) how'd it get into this state, and
> b) why doesn't fsck care ...
> 
> Looking into that . . .

So this is pre-existing corruption somehow' that 2nd 0-level
record's first logical block should match the first 1st-level
extent's logical block under it.  I was hoping you had just
run into some sort of extent tree traversal bug when looking
up this block, but I think you have an actual corruption in the
extent tree already.

You could work around this by just copying the file then renaming
it back, to get a different (presumably correct) extent tree.
But it'll be hard to work out how it got into this state, I don't
yet see how this can happen.  :(

Does your box wind up crashing or losing power, and replaying the
log once?  I'm wondering if it's possible that an extent tree
metadata update got lost in a crash . . .

-Eric

-Eric

  reply	other threads:[~2012-11-13 22:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-03 22:02 Weird filesystem corruption from wayland / radeon / chromium darxus
2012-09-04  3:29 ` Theodore Ts'o
2012-09-04  7:19   ` darxus
2012-09-05  2:48   ` darxus
2012-09-05  3:38     ` darxus
2012-11-02 15:50       ` Tim Landscheidt
2012-11-02 17:24         ` Eric Sandeen
2012-11-02 18:55           ` Tim Landscheidt
2012-11-13 18:28             ` Eric Sandeen
2012-11-13 22:13               ` Eric Sandeen [this message]
2012-11-12 22:00         ` Eric Sandeen
2012-11-15 22:01 ` Eric Sandeen
2012-11-15 23:38   ` Eric Sandeen

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=50A2C60B.1040405@redhat.com \
    --to=sandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).