linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sam Thursfield <sam.thursfield@codethink.co.uk>
To: cwillu <cwillu@cwillu.com>, linux-btrfs@vger.kernel.org
Subject: Re: Advice on FS corruption
Date: Mon, 03 Sep 2012 17:12:52 +0100	[thread overview]
Message-ID: <5044D704.4090905@codethink.co.uk> (raw)
In-Reply-To: <CAE5mzvgwXks1+6q+tL=AJR7q1HvduQA6S2KMP36-AT40jTkhtQ@mail.gmail.com>

[I'm resending this mail to list instead of as a personal reply, sorry]

On 09/03/2012 03:35 PM, cwillu wrote:
> On Mon, Sep 3, 2012 at 8:23 AM, Sam Thursfield
> <sam.thursfield@codethink.co.uk> wrote:
>> Hi
>>
>> I've been running btrfs in various VMs for a while, and periodically I've
>> experienced corruption in the filesystems being used. None of the data is
>> important, but I'd like to track down how the corruption occurred in the
>> first place.
>>
>> Trying to mount any of the corrupt filesystems fails with an error of this
>> form:
>>
>> [   47.805146] device label baserock devid 1 transid 90 /dev/sdb1
>> [   47.810073] btrfs: disk space caching is enabled
>> [   47.817261] parent transid verify failed on 1636728832 wanted 76 found 95
>> [   47.818081] parent transid verify failed on 1636728832 wanted 76 found 95
>> [   47.818522] Failed to read block groups: -5
>> [   47.826103] btrfs: open_ctree failed
>
> Try mounting with -o recovery.
>

Thanks, this gets more interesting!

For two of the FS's I got the exact same error message.

For a much larger (40GB) filesystem the recovery silently succeeded. At 
this point I ran 'find' in the root directory, which gave frequent:

find: ./foo: Input/output error

messages for various small files. I aborted and found all this in dmesg:

[   29.498581] device fsid 7aaaea86-e354-46f7-aa9e-2278c858170a devid 1 
transid 35 /dev/sdb1
[   42.937330] parent transid verify failed on 31920128 wanted 9 found 26
[   42.961755] parent transid verify failed on 31920128 wanted 9 found 26
[   42.999560] parent transid verify failed on 31875072 wanted 9 found 26
[   43.035490] parent transid verify failed on 31875072 wanted 9 found 26
[   43.078782] parent transid verify failed on 31907840 wanted 9 found 26
[   43.079767] parent transid verify failed on 31907840 wanted 9 found 26
[   43.081685] parent transid verify failed on 31920128 wanted 9 found 26
[   43.082478] parent transid verify failed on 31920128 wanted 9 found 26
[   43.110576] parent transid verify failed on 31952896 wanted 9 found 27
[   43.112616] parent transid verify failed on 31952896 wanted 9 found 27

So, it seems to have improved matters, but am I correct in thinking this 
FS would now only be suitable for extracting as much of the data as 
possible and then discarding the whole thing? Or is the intention that 
an FS in such a state should be recovered to the point of being usable 
again?

Thanks
Sam



      reply	other threads:[~2012-09-03 16:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-03 14:23 Advice on FS corruption Sam Thursfield
2012-09-03 14:35 ` cwillu
2012-09-03 16:12   ` Sam Thursfield [this message]

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=5044D704.4090905@codethink.co.uk \
    --to=sam.thursfield@codethink.co.uk \
    --cc=cwillu@cwillu.com \
    --cc=linux-btrfs@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).