Re: Mount issue, mount /dev/sdc2: can't read superblock

From: "Tomáš Metelka" <tomas.metelka@metaliza.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Peter Chant <pete@petezilla.co.uk>,
	Chris Murphy <lists@colorremedies.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Mount issue, mount /dev/sdc2: can't read superblock
Date: Mon, 24 Dec 2018 14:52:44 +0100	[thread overview]
Message-ID: <682fc519-49c4-8537-bd48-cff246a39092@metaliza.cz> (raw)
In-Reply-To: <d29c3f7f-33b8-e1fc-e6ae-672a5bf52376@gmx.com>

On 24. 12. 18 14:02, Qu Wenruo wrote:
> btrfs check --readonly output please.
> 
> btrfs check --readonly is always the most reliable and detailed output
> for any possible recovery.

This is very weird because it prints only:
ERROR: cannot open file system

I've tried also "btrfs check -r 75152310272" but it only says:
parent transid verify failed on 75152310272 wanted 2488742 found 2488741
parent transid verify failed on 75152310272 wanted 2488742 found 2488741
Ignoring transid failure
ERROR: cannot open file system

I've tried that because:
	backup 3:
  backup_tree_root:	75152310272	gen: 2488741 level: 1

> Also kernel message for the mount failure could help.

Sorry, my fault, I should start from this point:

Dec 23 21:59:07 tisc5 kernel: [10319.442615] BTRFS: device fsid 
be557007-42c9-4079-be16-568997e94cd9 devid 1 transid 2488742 /dev/loop0
Dec 23 22:00:49 tisc5 kernel: [10421.167028] BTRFS info (device loop0): 
disk space caching is enabled
Dec 23 22:00:49 tisc5 kernel: [10421.167034] BTRFS info (device loop0): 
has skinny extents
Dec 23 22:00:50 tisc5 kernel: [10421.807564] BTRFS critical (device 
loop0): corrupt node: root=1 block=75150311424 slot=245, invalid NULL 
node pointer
Dec 23 22:00:50 tisc5 kernel: [10421.807653] BTRFS error (device loop0): 
failed to read block groups: -5
Dec 23 22:00:50 tisc5 kernel: [10421.877001] BTRFS error (device loop0): 
open_ctree failed

So i tried to do:
1) btrfs inspect-internal dump-super (with the snippet posted above)
2) btrfs inspect-internal dump-tree -b 75150311424

And it showed (header + snippet for items 243-248):
node 75150311424 level 1 items 249 free 244 generation 2488741 owner 2
fs uuid be557007-42c9-4079-be16-568997e94cd9
chunk uuid dbe69c7e-2d50-4001-af31-148c5475b48b
...
   key (14799519744 EXTENT_ITEM 4096) block 233423224832 (14247023) gen 
2484894
   key (14811271168 EXTENT_ITEM 135168) block 656310272 (40058) gen 2488049
   key (1505328190277054464 UNKNOWN.4 366981796979539968) block 0 (0) gen 0
   key (0 UNKNOWN.0 1419267647995904) block 6468220747776 (394788864) 
gen 7786775707648
   key (12884901888 EXTENT_ITEM 24576) block 816693248 (49847) gen 2484931
   key (14902849536 EXTENT_ITEM 131072) block 75135844352 (4585928) gen 
2488739

I looked at that numbers quite a while (also in hex) trying to figure 
out what has happened (bit flips (it was on SSD), byte shifts (I 
suspected bad CPU also ... because it has died after 2 months from 
that)) and tried to guess "correct" values for that items ... but no idea:-(

So this why I have asked about that log_root and whether there is a 
chance to "log-replay things":-)

Thanks
M.