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