Sorry, that was really just a sample of output rather then a run-through of my steps. Also, I captured an image of the partition so I could re-install my OS. I did try btrfs-zero-log first, but not btrfs rescue super-recover (as I was afraid it might break my superblock). I will try the latest 3.17rc and btrfs-progs integration (one at a time) when I get a chance. # btrfs-zero-log btrfs.img Check tree block failed, want=688963584, have=0 Check tree block failed, want=688963584, have=0 Check tree block failedd, want=688963584, have=0 read block failed check_tree_block Couldn't setup extent tree #btrfs-debug-tree -R btrfs.img Check tree block failed, want=688963584, have=0 Check tree block failed, want=688963584, have=0 Check tree block failed, want=688963584, have=0 read block failed check_tree_block Couldn't setup extent tree Check tree block failed, want=686817280, have=0 Check tree block failed, want=686817280, have=0 Check tree block failed, want=686817280, have=0 read block failed check_tree_block Couldn't setup csum tree Check tree block failed, want=687718400, have=0 Check tree block failed, want=687718400, have=0 Check tree block failed, want=687718400, have=0 read block failed check_tree_block Couldn't setup log root tree unable to open btrfs.img On Mon, Sep 15, 2014 at 8:16 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Sep 15, 2014, at 6:56 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > >> >> On Sep 15, 2014, at 3:41 PM, Tony Murray <murraytony@xxxxxxxxx> wrote: >>> >>> # btrfs restore -v -i /dev/sda7 /mnt/sdb1/ >> >> Starting with umounted volume: >> >> btrfs check <dev> >> btrfs-debug-tree -R <dev> > > Oh nevermind I just saw that you did a btrfsck --repair, so you really kinda got the sequence wrong by doing that so soon and without list advice. I don't see whether you tried btrfs-zero-log first, or btrfs rescue super-recover, did you? > > btrfs-debug-tree -R should show four backup slots, and it's possible to plug in the tree root block value into btrfs restore -t, and maybe extract some data. And then it gets more aggressive from there, by seeing if you get any different recovery results with kernel 3.17rc5; and then it's btrfs-progs integration branch territory to see if maybe btrfs-zero-log or btrfs check will do something differently. > > > Chris Murphy-- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
