btrfs raid0 unable to mount

btrfs raid0 unable to mount

[lilofile]

when I use two disk to create raid0 in btrfs, after rebooting
system,one disk unable to mount ,
error is as follows:
mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

in /var/log/kern.log

 kernel: [  480.962487] btrfs: failed to read the system array on md0
 kernel: [  480.988400] btrfs: open_ctree failed

Re: btrfs raid0 unable to mount

[Brendan Hide]

On 2013/10/26 06:19 AM, lilofile wrote:
> when I use two disk to create raid0 in btrfs, after rebooting
> system,one disk unable to mount ,
> error is as follows:
> mount: wrong fs type, bad option, bad superblock on /dev/md0,
>         missing codepage or helper program, or other error
>         In some cases useful info is found in syslog - try
>         dmesg | tail  or so
>
> in /var/log/kern.log
>
>   kernel: [  480.962487] btrfs: failed to read the system array on md0
>   kernel: [  480.988400] btrfs: open_ctree failed
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
At first glance, this looks confusing since it is referring to md0, 
which would be md's raid.

Is it a btrfs-raid0 using an md-raid-something-else -> Or is it simply 
btrfs on top of an md-raid0?

     cat /proc/mdstat
and
     btrfs fi show
will answer those queries.

-- 
__________
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97

Re: btrfs raid0 unable to mount

[Duncan]

lilofile posted on Sat, 26 Oct 2013 12:19:16 +0800 as excerpted:

> when I use two disk to create raid0 in btrfs, after rebooting system,one
> disk unable to mount ,
> error is as follows:
> mount: wrong fs type, bad option, bad superblock on /dev/md0,
>        missing codepage or helper program, or other error In some cases
>        useful info is found in syslog - try dmesg | tail  or so
> 
> in /var/log/kern.log
> 
>  kernel: [  480.962487] btrfs: failed to read the system array on md0
>  kernel: [  480.988400] btrfs: open_ctree failed

You left more questions than you provided answers.  Among them...

So you're using md/raid to create the raid0, not btrfs raid0 mode, or did 
you mean that you created a btrfs raid0 mode filesystem on top of one or 
more md/raid devices?

Did you assemble the mdraid before trying to mount and were there any 
errors or interesting messages related to that?

With what options did you create the btrfs on the md device?  Was the 
btrfs a multi-device filesystem on top of the mdraid as well, or just the 
single md0 device?  If a multi-device btrfs, what modes were data/
metadata, and among how many devices?  Were they all different md/raid 
devices, or...?

And why did you create an mdraid instead of using pure btrfs raid modes?  
(Not that there aren't reasons to do so.  md/raid 5/6 should be far more 
reliable than the still incomplete btrfs raid56 mode, for instance, so if 
you were doing raid5/6, that'd be a reason.)

Meanwhile, if the btrfs was indeed a multi-device filesystem, not simply 
built on top of a single md/raid device, it's worth noting that the 
kernel needs to know which devices to create the multi-device btrfs out 
of.  Normally, that's done with a btrfs device scan before the attempt to 
mount (in an initr* if the btrfs is system root), but individual 
device=/dev/whatever options can be passed to mount instead, if running 
btrfs device scan is inconvenient for some reason.

(However, it should be noted that the usual rootflags= kernel commandline 
parameter to pass root mount options appears to be broken with the 
device= option, or at least it was a couple kernels ago when I tried it.  
I'd guess the kernel gets confused seeing two or more equals characters 
in the same commandline parameter and tries to parse it as 
rootflags=device= instead of simply rootflags=, and it rightly doesn't 
recognize the former as something it knows how to process.  Thus, at that 
point it seemed an initr* was required to mount a multi-device btrfs 
root, likely with the btrfs command in the initr* in ordered to do btrfs 
device scan, the solution I'm using here ATM, using dracut as my initr* 
generator, and I've seen no indication that said kernel commandline 
parsing bug may have been fixed yet, tho I suppose it's possible as I've 
not tested it since then, either.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman