On 2014-09-19 13:54, Chris Murphy wrote:
From what I can tell, btrfs check doesn't do anything about backup superblocks unless you specifically tell it to. In this case, running btrfs check without specifying a superblock mirror, and with explicitly specifying the primary superblock produced identical results (namely it choked, hard, with an error message similar to that from the kernel. However, running it with -s1 to select the first backup superblock returned no errors at all other than the space_cache being invalid and the count of used blocks being wrong.On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn <ahferro...@gmail.com> wrote: [ 30.920536] BTRFS: bad tree block start 0 130402254848 [ 30.924018] BTRFS: bad tree block start 0 130402254848 [ 30.926234] BTRFS: failed to read log tree [ 30.953055] BTRFS: open_ctree failed I'm still confused. Btrfs knows this tree root is bad, but it has backup roots. So why wasn't one of those used by -o recovery? I thought that's the whole point of that mount option. Backup tree roots are per superblock, so conceivably you'd have up to 8 of these with two superblocks, they're shown with btrfs-show-super -af ## and -F even if a super is bad But skipping that, to fix this you need to know which super is pointing to the wrong tree root, since you're using ssd mount option with rotating supers. I assume mount uses the super with the highest generation number. So you'd need to: btrfs-show-super -a to find out the super with the most recent generation. You'd assume that one was wrong. And then use btrfs-select-super to pick the right one, and replace the wrong one. Then you could mount. I also wonder if btrfs check -sX would show different results in your case. I'd think it would because it ought to know one of those tree roots is bad, seeing as mount knows it. And then it seems (I'm speculating a ton) that --repair might try to fix the bad tree root, and then if it fails I'd like to think it can just find the most recent good tree root, ideally one listed as a backup_tree_root by any good superblock, and then have the next mount use that. I'm not sure why this persistently fails, and I wonder if there are cases of users giving up and blowing away file systems that could actually be mountable. But it's just really a manual process figuring out what things to do in what order to get them to mount.
Based on my (limited) understanding of the mount code, it does try to use the superblock with the highest generation (regardless of whether we are on an ssd or not), but doesn't properly fall back to a secondary superblock after trying to mount using the primary.
As far as btrfs check repair trying to fix this, I don't think that it does so currently, probably for the same reason that mount fails.
smime.p7s
Description: S/MIME Cryptographic Signature
