Re: Recovering data from disk with loose cable

[Ben Gamari]

On Wed, 9 Feb 2011 21:46:38 -0500, Ben Gamari bgam...@gmail.com wrote:
 We have a disk array behind two external SATA port multipliers (four
 disks on each multiplier) which has been running btrfs (RAID 1 for
 both data and metadata). Unfortunately, earlier today it seems one of
 the SATA cables came loose, resulting in the kernel (2.6.37)
 eventually OOPSing although apparently not before writing quite a bit
 of data. Upon reboot, I was met with the dreaded,
 
 disk-io.c:741: open_ctree_fd: Assertion `!(!tree_root-node)' failed.
 
 Unfortunately any attempt to run any of the btrfs-progs utilities
 (from git) met a similar end. There was recently a patch to try harder
 in recovering from this problem posted to the list[1], although
 unfortunately it is unable to find a root. Considering there are eight
 disks in the array and only four were affected by the loose cable, I
 find it very hard to believe there is no way to recover this volume.
 Any suggestions at all would be greatly appreciated. Recovering this
 data would mean a lot. Thanks,
 
Given there has been no response to this, I suppose I should assume this
data is unrecoverable? It's not the end of the world if so, but again,
it would be nice to get a few files and it seems like a small subset of
the metadata is corrupted.

Cheers,

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

Recovering data from disk with loose cable

[Ben Gamari]

We have a disk array behind two external SATA port multipliers (four
disks on each multiplier) which has been running btrfs (RAID 1 for
both data and metadata). Unfortunately, earlier today it seems one of
the SATA cables came loose, resulting in the kernel (2.6.37)
eventually OOPSing although apparently not before writing quite a bit
of data. Upon reboot, I was met with the dreaded,

disk-io.c:741: open_ctree_fd: Assertion `!(!tree_root-node)' failed.

Unfortunately any attempt to run any of the btrfs-progs utilities
(from git) met a similar end. There was recently a patch to try harder
in recovering from this problem posted to the list[1], although
unfortunately it is unable to find a root. Considering there are eight
disks in the array and only four were affected by the loose cable, I
find it very hard to believe there is no way to recover this volume.
Any suggestions at all would be greatly appreciated. Recovering this
data would mean a lot. Thanks,

- Ben


[1] https://patchwork.kernel.org/patch/506631/

[2] Output from patched btrfsck

$ sudo ./btrfsck /dev/sdj
trying potential super #0 at bytenr 65536
super #0 at bytenr 65536 has better generation 43887 than 0, using that
trying potential super #1 at bytenr 67108864
super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping
   warning: super #1 at bytenr 67108864 has different contents!
trying potential super #2 at bytenr 274877906944
super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping
   warning: super #2 at bytenr 274877906944 has different contents!
trying potential super #0 at bytenr 65536
super #0 at bytenr 65536 has better generation 43887 than 0, using that
trying potential super #1 at bytenr 67108864
super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping
   warning: super #1 at bytenr 67108864 has different contents!
trying potential super #2 at bytenr 274877906944
super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping
   warning: super #2 at bytenr 274877906944 has different contents!
trying potential super #0 at bytenr 65536
super #0 at bytenr 65536 has better generation 43887 than 0, using that
trying potential super #1 at bytenr 67108864
super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping
   warning: super #1 at bytenr 67108864 has different contents!
trying potential super #2 at bytenr 274877906944
super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping
   warning: super #2 at bytenr 274877906944 has different contents!
trying potential super #0 at bytenr 65536
super #0 at bytenr 65536 has better generation 43887 than 0, using that
trying potential super #1 at bytenr 67108864
super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping
   warning: super #1 at bytenr 67108864 has different contents!
trying potential super #2 at bytenr 274877906944
super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping
   warning: super #2 at bytenr 274877906944 has different contents!
trying potential super #0 at bytenr 65536
super #0 at bytenr 65536 has better generation 43887 than 0, using that
trying potential super #1 at bytenr 67108864
super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping
   warning: super #1 at bytenr 67108864 has different contents!
trying potential super #2 at bytenr 274877906944
super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping
   warning: super #2 at bytenr 274877906944 has different contents!
trying potential super #0 at bytenr 65536
super #0 at bytenr 65536 has better generation 43884 than 0, using that
trying potential super #1 at bytenr 67108864
super #1 at bytenr 67108864 has same generation 43884 than 43884, skipping
   warning: super #1 at bytenr 67108864 has different contents!
trying potential super #2 at bytenr 274877906944
super #2 at bytenr 274877906944 has same generation 43884 than 43884, skipping
   warning: super #2 at bytenr 274877906944 has different contents!
trying potential super #0 at bytenr 65536
super #0 at bytenr 65536 has better generation 43884 than 0, using that
trying potential super #1 at bytenr 67108864
super #1 at bytenr 67108864 has same generation 43884 than 43884, skipping
   warning: super #1 at bytenr 67108864 has different contents!
trying potential super #2 at bytenr 274877906944
super #2 at bytenr 274877906944 has same generation 43884 than 43884, skipping
   warning: super #2 at bytenr 274877906944 has different contents!
trying potential super #0 at bytenr 65536
super #0 at bytenr 65536 has better generation 43884 than 0, using that
trying potential super #1 at bytenr 67108864
super #1 at bytenr 67108864 has same generation 43884 than 43884, skipping
   warning: super #1 at bytenr 67108864 has different contents!
trying potential super #2 at bytenr 274877906944
super #2 at bytenr 274877906944 has same generation 43884 than 43884, skipping
   warning: super #2 at