Re: Problem with unmountable filesystem.

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2876 bytes --]

On 2014-09-19 13:54, Chris Murphy wrote:
>
> On Sep 17, 2014, at 5:23 AM, Austin S Hemmelgarn <ahferroin7@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.
>
 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.

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.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]