Re: btrfs raid5 unmountable

[Tetja Rediske]

Hello Duncan,

 Of course if you'd been following the list as btrfs testers really
 should still be doing at this point, you'd have seen all this covered
 before. And of course, if you had done pre-deployment testing before
 you stuck valuable data on that btrfs raid5, you'd have noted the
 problems, even without reading about it on-list or on the wiki.  But
 of course hindsight is 20/20, as they say, and at least you DO have
 backups, even if they'll take awhile to restore.  =:^) That's already
 vastly better than a lot of the reports we unfortunately get here.
 =:^\

yeah, i saw it. Main reason for me toying with btrfs is my work. We
rent Linux servers to customers. While they install and manage them by
them self, there will be questions about btrfs to our support, sooner or
later. So getting your hands on it early saves some headache later.

It is just inconvient for me now, so no big deal.

I first tried degraded, I also tried repair, no luck.

What I do now is, getting as much data from the broken fs with btrfs
recover and do a rsync after. It is just faster then downloading all
the data from my own mirror in the datacenter. ;)

After that I will even be so crazy and try it again. Next on my list is
send/receive. 

Tetja



--
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

btrfs raid5 unmountable

[Tetja Rediske]

Hi,

since Freenode is doomed today, i ask the direct way.

Following Filesystem:

Label: 'data'  uuid: 3a6fd6d7-5943-4cad-b56f-2e6dcabff453
Total devices 6 FS bytes used 7.02TiB
devid1 size 1.82TiB used 1.82TiB path /dev/sda3
devid2 size 2.73TiB used 2.48TiB path /dev/sdc3
devid3 size 931.38GiB used 931.38GiB path /dev/sdd3
devid5 size 931.51GiB used 931.51GiB path /dev/sde1
devid6 size 931.51GiB used 931.51GiB path /dev/sdf1
devid7 size 2.73TiB used 2.48TiB path /dev/sdb3

Btrfs v3.12-dirty

If I try to mount it from dmesg:

[30644.681210] parent transid verify failed on 32059176910848 wanted
259627 found 259431 
[30644.681307] parent transid verify failed on 32059176910848 wanted
259627 found 259431 
[30644.681399] btrfs bad tree block start 0 32059176910848 
[30644.681407] Failed to read block groups: -5 
[30644.776879] btrfs: open_ctree failed

btrfs check aborts with (many of the 1st lines)

[...] 
Ignoring transid failure parent transid verify failed on 32059196616704
wanted 259627 found 259432
parent transid verify failed on 32059196616704 wanted 259627 found
259432 Check tree block failed, want=32059196616704, have=32059196747776

parent transid verify failed on 32059196616704 wanted 259627 found259432
Ignoring transid failure
parent transid verify failed on 32059196616704 wanted 259627 found259432
Ignoring transid failure
parent transid verify failed on 32059177230336 wanted 259627 found259431
Ignoring transid failure
parent transid verify failed on 32059196620800 wanted 259627 found259432
parent transid verify failed on 32059196620800 wanted 259627 found259432
Check tree block failed, want=32059196620800, have=1983699371120445514
Check tree block failed, want=32059196620800, have=1983699371120445514
Check tree block failed, want=32059196620800, have=1983699371120445514
read block failed check_tree_block
btrfs: cmds-check.c:2212: check_owner_ref: Assertion `!(rec-is_root)'
failed.
Aborted

What happened before:

One disk was faulty, I added a new one and removed the old one,
followed by a balance.

So far so good.

Some days after this I accidently removed a SATA Power Connector from
another drive, without noticing it at first. Worked about an hour on
the system, building new Kernel on another Filesystem. Rebooted with my
new Kernel and the FS was not mountable. I noticed the missing disk
and reattached the power.

So far i tried:

mount -o recovery
btrfs check
(after google) btrfs-zero-log

Sadly no luck. Whoever I can get my Files with btrfs restore. The
Filesystem contains mainly Mediafiles, so it is not so bad, if they
were lost, but restoring them from backups and sources will need
atleast about a week. (Most of the Files are mirrored on a private
Server, but even with 100MBit this takes a lot of time ; )

Some Idea who to recover this FS?

Kind Regards
Tetja Rediske




--
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