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?
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/
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
