On Sep 16, 2014, at 1:36 PM, Tony Murray <murraytony@xxxxxxxxx> wrote: > 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). You could still try: btrfs rescue super-recover -v <dev> It will show you whether they are good or bad and which is which. And if they're good it won't fix anything. If one is bad it'll first ask you if it's a Btrfs fs before it tries to fix it. You can answer n if you don't want to try fixing it. At least, I get a crash, but it does fix corrupt csum before that. It's also possible to use: btrfs-show-super -afF <dev> This will show all supers, even if any are bad, it won't fix anything. But it's going to spit out a lot more info. Then it's possible to try: btrfs check -s0 <dev> btrfs check -s1 <dev> to see if you get any different result; the first one will still be really bad because it's the same as default, but if the second one looks better then it might be that you either have a bad superblock, or a good one pointing to a bad root tree. In which case it may still be possible to fix. 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
