On 09/17/2014 02:57 PM, Chris Murphy wrote: > > On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn <ahferro...@gmail.com> wrote: >> >> Thanks for all the help. > > Well, it's not much help. It seems possible to "corrupt" a primary superblock > that points to a corrupt tree root, and use btrfs rescure super-recover to > replace it, and then mount should work. One thing I didn't try was corrupting > the primary superblock and just mounting normally or with recovery, to see if > it'll automatically ignore the primary superblock and use the backup. > > But I think you're onto something, that a good superblock can point to a > corrupt tree root, and then not have a straight forward way to mount the good > tree root. If I understand this correctly. > Corrupting the primary superblock did in fact work, and I decided to try mounting immediately, which failed. I didn't try with -o recovery, but I think that would probably fail as well. Things worked perfectly however after using btrfs rescue super-recover. As far as avoiding future problems, I think the best solution would be to have the mount operation try the tree root pointed to by the backup superblock if the one pointed to by the primary seems corrupted.
Secondarily, this almost makes me want to set the ssd option on all BTRFS filesystems, just to get the rotating superblock updates, because if it weren't for that behavior, I probably wouldn't have been able to recovery anything in this particular case. -- 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
