Corrupt file system, unfixable by btrfsck

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear btrfs developers,

I'm using btrfs on my laptop. Yesterday night, after resuming from suspend to 
disk, I got some serious file system corruption. Unfortunately I didn't have 
too close a look at the kernel messages.  It started with website loading only 
half working and inability to start programs. dmesg showed some stack traces 
involving btrfs. On reboot, the kernel is unable to mount the file system.

I made an image of the broken file system and am currently restoring my laptop 
from backup. I successfully recovered the few files that changes since the 
backup using the restore tool from josefbacik's repo. To be precise: it's 
open_ctree_broken function succeeds in accessing the tree when I run it with -
u 2 (which as I understand it, tells it to use a non-existing copy of the 
super block):

nine@sphinx:~/backup> ../install/btrfs-progs/restore sunshine.img restore/
Check tree block failed, want=102930456576, have=0
Check tree block failed, want=102930456576, have=0
Check tree block failed, want=102930456576, have=0
Check tree block failed, want=102930456576, have=0
Check tree block failed, want=102930456576, have=0
read block failed check_tree_block
Segmentation fault
nine@sphinx:~/backup> ../install/btrfs-progs/restore -u 2 sunshine.img 
restore/
No valid Btrfs found on sunshine.img
Could not open root, trying backup super
Ok couldn't open the root the normal way, trying the broken way

(at this point it restores the fs).

Trying to mount the image gives the same messages as on the laptop:

[254473.929074] device label root devid 1 transid 130471 /dev/loop1
[254473.943910] btrfs: disk space caching is enabled
[254473.946369] btrfs bad tree block start 0 102930456576
[254473.946379] btrfs bad tree block start 0 102930456576
[254473.946393] Failed to read block groups: -5
[254473.946612] btrfs: open_ctree failed

I'm running a 3.7.0-rc4 kernel. Attaching the output of btrfsck (compressed, 
since it's > 700k). Attempts to repair the file systems fail. But I guess, 
since open_ctree_broken succeds, btrfsck could be tought that as well?

Regards,
Stefan Seifert

Attachment: btrfsck.log.xz
Description: application/xz


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux