Michael Andreen
2012-Jan-05 22:59 UTC
Filesystem not mountable after reset, bad tree block
Hi, Today one of my machines (running kernel 3.0.6) locked up, sadly the monitor was stuck in power saving mode and no access over network so not sure exactly what happened. After restarting the machine, the root filesystem is no longer mountable the following output appears: device label SSD devid 1 transid 507930 /dev/sdb2 btrfs bad tree block start 0 188205998080 btrfs bad tree block start 0 188205998080 btrfs bad tree block start 0 188205998080 btrfs: open_ctree failed I downloaded the latest btrfs-progs, but getting similar output from several of the programs: # ./btrfs-debug-tree /dev/sdb2 Check tree block failed, want=188205998080, have=0 Check tree block failed, want=188205998080, have=0 Check tree block failed, want=188205998080, have=0 Check tree block failed, want=188205998080, have=0 Check tree block failed, want=188205998080, have=0 read block failed check_tree_block btrfs-debug-tree: disk-io.c:447: find_and_setup_root: Assertion `!(!root->node)'' failed.Aborted The find-root program seems to think there is a root (and poentially some older roots?), but not sure how to use that information. # ./find-root /dev/sdb2 Super think''s the tree root is at 131212083200, chunk root 20983808 Well block 13856997376 seems great, but generation doesn''t match, have=321485, want=507930 Well block 16362573824 seems great, but generation doesn''t match, have=317992, want=507930 Well block 16367947776 seems great, but generation doesn''t match, have=321490, want=507930 Well block 36317024256 seems great, but generation doesn''t match, have=195981, want=507930 Well block 39698722816 seems great, but generation doesn''t match, have=273675, want=507930 Well block 39714439168 seems great, but generation doesn''t match, have=320627, want=507930 Well block 43016519680 seems great, but generation doesn''t match, have=272156, want=507930 Well block 43031748608 seems great, but generation doesn''t match, have=302652, want=507930 Well block 47617982464 seems great, but generation doesn''t match, have=274708, want=507930 Found tree root at 131212083200 Anything else I can do to debug this or potentially recover a few bits before reformatting? /Michael -- 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
Hi! Michael Andreen <harv@ruin.nu> schrieb:> The find-root program seems to think there is a root (and poentially some > older roots?), but not sure how to use that information.[...]> Anything else I can do to debug this or potentially recover a few bits > before reformatting?You could try the recovery programs from Josefs btrfs-progs tree[1]. You could also try using kernel 3.2 which allows mounting in recovery mode. This mode tries to find an older tree root. But I think your kernel did not keep tree root backups for this purpose as it is AFAIR a feature of later kernels. Better use a newer kernel - best use 3.2. There are bunch of fixes which improve the situation with lost file systems after unexpected reboots or power outages. HTH Kai [1] https://github.com/josefbacik/btrfs-progs -- 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
On Sat, Jan 07, 2012 at 01:05:08PM +0100, Kai Krakow wrote:> Hi! > > Michael Andreen <harv@ruin.nu> schrieb: > > The find-root program seems to think there is a root (and poentially some > > older roots?), but not sure how to use that information. > [...] > > Anything else I can do to debug this or potentially recover a few bits > > before reformatting? > > You could try the recovery programs from Josefs btrfs-progs tree[1].You''ll find what little documentation we have on the restore program here: http://btrfs.ipv5.de/index.php?title=Restore With luck, you''ll just need to run restore, but there''s also a little bit on how to read and use the output of find-root. Hugo.> You > could also try using kernel 3.2 which allows mounting in recovery mode. This > mode tries to find an older tree root. But I think your kernel did not keep > tree root backups for this purpose as it is AFAIR a feature of later > kernels. > > Better use a newer kernel - best use 3.2. There are bunch of fixes which > improve the situation with lost file systems after unexpected reboots or > power outages. > > HTH > Kai > > [1] https://github.com/josefbacik/btrfs-progs >-- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk == PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Computer Science is not about computers, any more than --- astronomy is about telescopes.
Michael Andreen
2012-Jan-08 22:34 UTC
Re: Filesystem not mountable after reset, bad tree block
On Saturday 07 January 2012 17:01:40 Hugo Mills wrote:> On Sat, Jan 07, 2012 at 01:05:08PM +0100, Kai Krakow wrote: > > > > You could try the recovery programs from Josefs btrfs-progs tree[1]. > > You''ll find what little documentation we have on the restore > program here: > > http://btrfs.ipv5.de/index.php?title=Restore > > With luck, you''ll just need to run restore, but there''s also a > little bit on how to read and use the output of find-root.Thanks, it worked very well. Almost disappointed that it managed to recover all the junk accumulated through the years ;) It had some problems on certain parts, crashing or just exiting with message about "extent buffer leak", but rerunning it without -o made it continue past that point. Not sure if that''s normal or known, I''ll keep the image around and see if I have time to debug it. /Michael -- 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