Re: btrfs check --repair is clean, but mount fails

On Fri, Feb 26, 2016 at 06:45:34PM -0800, Liu Bo wrote:

On Fri, Feb 26, 2016 at 06:39:38PM -0800, Marc MERLIN wrote:

quoted

btrfs-tools 4.4-1
gargamel:~# uname -r
4.4.2-amd64-i915-volpreempt-20160214bc2

2 drive array stopped working after a crash/reboot. Check --repair finds nothing wrong with it:

gargamel:~# btrfs check --repair /dev/mapper/raid0d1
enabling repair mode
Checking filesystem on /dev/mapper/raid0d1
UUID: 01334b81-c0db-4e80-92e4-cac4da867651
checking extents
Fixed 0 roots.
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
checking csums
checking root refs
found 1201345524312 bytes used err is 0
total csum bytes: 1165124220
total tree bytes: 8258322432
total fs tree bytes: 5574197248
total extent tree bytes: 1020428288
btree space waste bytes: 1902023247
file data blocks allocated: 1193398628352
 referenced 1209324777472
gargamel:~# mount /var/local/space
mount: wrong fs type, bad option, bad superblock on /dev/mapper/raid0d1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
[ 8200.511021] BTRFS info (device dm-6): disk space caching is enabled
[ 8200.533030] BTRFS: failed to read the system array on dm-6
[ 8200.582097] BTRFS: open_ctree failed

Does 'btrfs dev scan' help?

 
Oh my, it does...
gargamel:~# btrfs dev scan
Scanning for Btrfs filesystems
gargamel:~# mount /var/local/space

[14477.028083] BTRFS: device label btrfs_space devid 2 transid 776784 /dev/mapper/raid0d2
[14500.262307] BTRFS info (device dm-7): disk space caching is enabled
[14504.042485] BTRFS: checking UUID tree

Err, I'm very perplexed now. I already have a scan in my boot process after device decrypts. 
Somehow it saw one of my 2 devices, but not the other one?

I'm looking at my boot:
[  112.063677] BTRFS: device label btrfs_space devid 1 transid 776782 /dev/mapper/raid0d1
[  112.090192] BTRFS info (device dm-6): disk space caching is enabled
[  112.111740] BTRFS: failed to read the system array on dm-6
[  112.160047] BTRFS: open_ctree failed
[  112.269710] BTRFS info (device dm-6): disk space caching is enabled
[  112.291430] BTRFS: failed to read the system array on dm-6
[  112.320104] BTRFS: open_ctree failed

So dm-6 is: raid0d1 -> ../dm-6

So, raid0d1 had an issue, btrfs check didn't really report any, for some unknown 
reason this caused raid0d2 not to be scanned, and in turn this caused
mounting that filesystem to fail?

Or did btrfs check actually fix something that I missed?
Any why would scan have missed raid0d2 the first time around?

Is it complaining that it can't read btrfs structures from raid0d1 because raid0d2
wasn't known yet? I'm not too sure what open_ctree means in that context.

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/