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