All of lore.kernel.org
 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 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.