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,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or 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 uuid: c2384ce9-bd38-480d-8b3b-fca6bd7921ac
Total devices 1 FS bytes used 82.52GB
devid 1 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
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 -- 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
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> wrote:> 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 > > > -- > 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 >-- 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