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

[Anand Jain <anand.jain@oracle.com>]

On 02/27/2016 11:03 AM, Marc MERLIN wrote:
> 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:
>>> 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.

   Can you log the output of blkid here. If blkid output does
   not report all the btrfs devs correctly the kernel won't know
   as well.

Thanks, Anand


> 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
>