On Fri, Feb 26, 2016 at 07:03:04PM -0800, 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.
> 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?
I feel confused, too.
Can you grep this message since btrfs dev scan has a "printf("Scanning for
Btrfs filesystems\n");"?
And if a scan failed somehow, it may print an error after this message
and we then know what was happening..
>
> 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.
No idea about this, not sure if it's due to any dependency?
Thanks,
-liubo
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
