Recover Corruption - verify_parent_transid

Recover Corruption - verify_parent_transid

[Jason Switzer]

I have a btrfs partition that is failing to mount and I was hoping I
could recover it somehow.
Mount returns immediately with a bad superblock error:

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
=A0=A0 =A0 =A0 missing codepage or helper program, or other error
=A0=A0 =A0 =A0 In some cases useful info is found in syslog - try
=A0=A0 =A0 =A0 dmesg | tail =A0or so

Looking in the syslog, we see the following errors:

[ 4328.614123] device fsid d4838bde94c38c2-ac2179bda6fc3b8b devid 1
transid 1133 /dev/sdb1
[ 4328.618807] parent transid verify failed on 117069225984 wanted
1133 found 812
[ 4328.619570] parent transid verify failed on 117069225984 wanted
1133 found 812
[ 4328.619928] parent transid verify failed on 117069225984 wanted
1133 found 812
[ 4328.621323] btrfs: open_ctree failed

These are the same errors that btrfsck returns, which I learned in
retrospect will not fix errors. Here is what btrfs-show returns:

Label: none =A0uuid: c2384ce9-bd38-480d-8b3b-fca6bd7921ac
          Total devices 1 FS bytes used 82.52GB
          devid =A0 =A01 size 1.82TB used 112.04GB path /dev/sdb1

Btrfs Btrfs v0.19

This system is running the following kernel:

$ uname -a
Linux erebus 2.6.32-gentoo-r7 #7 Sun May 30 21:33:03 CDT 2010 i686
Pentium III (Coppermine) GenuineIntel GNU/Linux

The system was busy copying files to the partition when it died due to
a power failure. The partition/device was not renamed between reboots.
The partition is a 2TB partition (big media drive), so if I have to
lose the data associated with the errors, I'd be okay with that
(rollback the transaction for that object or just remove the data
outright).

-Jason "s1n" Switzer
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Recover Corruption - verify_parent_transid

[A. James Lewis]

Not being one of the developers on this project, I cannot offer you a
solution to recovering data from this volume, and my guess is that a
ready solution is unlikely to be forthcoming simply because if this was
possible then btrfsck would include the code to recover the filesystem
already.

However, rather than simply observe that anything not backed up is
lost... I thought I would offer the solution of the 4th dimension....
The data is not "lost", but simply unavailable to you until the tools to
repair the filesystem have been developed further.  If I had something
critical which had become inaccessible, I might be tempted to put the
drive on a shelf for 6 months and see if btrfsck was able to repair
filesystems by then.  It may be that the on disk format is changed
before that happens, but I understand that this is now relatively
unlikely.

A. James Lewis

Re: Recover Corruption - verify_parent_transid

[Daniel Kozlowski]

I had a system in a simelar situation. In my case the fix was to
upgrade the btrfs module to git-head. After I did that tryig to mount
gave me an error is syslog about a problem it was having with one disk
before it went into the transid loop. i remove the disk and re-mounted
with -o degraded. hat allowed me to actually get teh drives mounted.
If your on a single disk setup i don't think that would work for you.
what you can do is check the syslog as you try to mount for  any OOP's
 that you may be able to fix.

On Tue, Aug 10, 2010 at 12:37 AM, A. James Lewis <james@fsck.co.uk> wro=
te:
> Not being one of the developers on this project, I cannot offer you a
> solution to recovering data from this volume, and my guess is that a
> ready solution is unlikely to be forthcoming simply because if this w=
as
> possible then btrfsck would include the code to recover the filesyste=
m
> already.
>
> However, rather than simply observe that anything not backed up is
> lost... I thought I would offer the solution of the 4th dimension....
> The data is not "lost", but simply unavailable to you until the tools=
 to
> repair the filesystem have been developed further. =A0If I had someth=
ing
> critical which had become inaccessible, I might be tempted to put the
> drive on a shelf for 6 months and see if btrfsck was able to repair
> filesystems by then. =A0It may be that the on disk format is changed
> before that happens, but I understand that this is now relatively
> unlikely.
>
> A. James Lewis
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs=
" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>



--=20
S.D.G.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html