Re: BSD disklabel and autodetection

Re: BSD disklabel and autodetection

[Hein Roehrig]

<martin@hack.org> writes:

> i'm trying to get autodetection to work on a RAID 5 raiddevice made up
> from three devices. two of them reside on disks with DOS-style partition
> tables, the third is on a disk with a BSD disklabel. all of them have the
> partition type set to 0xfd, but only the first two devices are configured
> at boot time.

See message <1019846049.1670.76.camel@peecee> on this mailing list. I
am in the process of patching my personal 2.4.19-rc3 to do
autodetection -- in the long run initrd is the way to go.

HTH,
Hein

BSD disklabel and autodetection

[martin]

hi all,

i'm trying to get autodetection to work on a RAID 5 raiddevice made up
from three devices. two of them reside on disks with DOS-style partition
tables, the third is on a disk with a BSD disklabel. all of them have the
partition type set to 0xfd, but only the first two devices are configured
at boot time.
the unit, which happens to be my root fs, still comes up but with only
two devices working.
i also have swap space configured as RAID1 over two BSD disklabel disks
which doesn't come up at all, and another RAID5 (/home) that doesn't
autodetect, so this is a bit of a problem to me.
if i run raidstart everything works fine, but that isn't an option for
root.
the same thing happens with kernel 2.4.4 and 2.4.18 - the BSD disklabel
partitions are not considered as autodetectable at boot time.

any ideas? i've tried to find information about this from the FAQ and
kernel mailinglists but can't figure out how to do it.

here's some output i get - md1 should consist of sdb5, sdd2 and sdc2 and
md0 of sda2 and sdb2:

md: autorun ...
md: considering sdd2 ...
md:  adding sdd2 ...
md:  adding sdc2 ...
md: created md1
md: bind<sdc2,1>
md: bind<sdd2,2>
md: running: <sdd2><sdc2>


many thanks in advance,

/m

Re: BSD disklabel and autodetection

[martin]

On 23 Jul 2002, Hein Roehrig wrote:
>
> <martin at hack.org> writes:
>
> > i'm trying to get autodetection to work on a RAID 5 raiddevice made up
> > from three devices. two of them reside on disks with DOS-style partition
> > tables, the third is on a disk with a BSD disklabel. all of them have the
> > partition type set to 0xfd, but only the first two devices are configured
> > at boot time.
>
> See message <1019846049.1670.76.camel@peecee> on this mailing list. I
> am in the process of patching my personal 2.4.19-rc3 to do
> autodetection -- in the long run initrd is the way to go.

Hein, i don't quite understand how initrd will solve my problem? i'm
quite happy with my handrolled kernel, it's just that some of the
partitions of the raid device are not detected.

following some hints i've seen elsewhere on the list i tried to pass md
parameters to the kernel ->

Booting on Nautilus using machine vector Nautilus from SRM
Command line: ro root=/dev/md1 md=1,/dev/sdb5,/dev/sdc2,/dev/sdd2 raid=noautodetect
md: Will configure md1 (super-block) from /dev/sdb5,/dev/sdc2,/dev/sdd2, below.

with the raid=noautodetect option it works.

what other raid/md options can be passed this way? and how do i configure
more than one device? geez, hope there's not a 256 char limit to the
command line...
are these options documented somewhere??


with regards,

/m

Re: BSD disklabel and autodetection

[martin]

hi - i'm resending this as it didn't seem to make the list first time.
sorry if you've already seen it.


On 23 Jul 2002, Hein Roehrig wrote:
> <martin at hack.org> writes:
> > i'm trying to get autodetection to work on a RAID 5 raiddevice made up
> > from three devices. two of them reside on disks with DOS-style partition
> > tables, the third is on a disk with a BSD disklabel. all of them have the
> > partition type set to 0xfd, but only the first two devices are configured
> > at boot time.
>
> See message <1019846049.1670.76.camel@peecee> on this mailing list. I
> am in the process of patching my personal 2.4.19-rc3 to do
> autodetection -- in the long run initrd is the way to go.

Hein, i don't quite understand how initrd will solve my problem? i'm
quite happy with my handrolled kernel, it's just that some of the
partitions of the raid device are not detected.

following some hints i've seen elsewhere on the list i tried to pass md
parameters to the kernel ->

Booting on Nautilus using machine vector Nautilus from SRM
Command line: ro root=/dev/md1 md=1,/dev/sdb5,/dev/sdc2,/dev/sdd2 raid=noautodetect
md: Will configure md1 (super-block) from /dev/sdb5,/dev/sdc2,/dev/sdd2, below.

with the raid=noautodetect option it works.

what other raid/md options can be passed this way? and how do i configure
more than one device? geez, hope there's not a 256 char limit to the
command line...
are these options documented somewhere??


with regards,

/m

Re: BSD disklabel and autodetection

[Michael Tokarev]

martin@hack.org wrote:
> 
[]
> following some hints i've seen elsewhere on the list i tried to pass md
> parameters to the kernel ->
> 
> Booting on Nautilus using machine vector Nautilus from SRM
> Command line: ro root=/dev/md1 md=1,/dev/sdb5,/dev/sdc2,/dev/sdd2 raid=noautodetect
> md: Will configure md1 (super-block) from /dev/sdb5,/dev/sdc2,/dev/sdd2, below.
> 
> with the raid=noautodetect option it works.
> 
> what other raid/md options can be passed this way? and how do i configure
> more than one device? geez, hope there's not a 256 char limit to the
> command line...

You may use md=N,dev1,dev2,... option as many times as you want, i.e.

 linux root=... md,1=/dev/sda1,.. md=2,/dev/sda2,...

I think that it's sufficient to tell it about only ONE member of
an array this way if your raid device has persistent superblock
(kernel will read superblock from first disk (or second for that
matter - if you choose to tell it about second disk) and read
other devices from there).

About other options - there are only two, raid= (e.g. noautodetect)
and md= (above) that are raid-related.

> are these options documented somewhere??

I personally looked at sources in drivers/md/ directory and got the
above line by reading initialization functions.  Maybe it's documented
somewhere in Documentation/... ;)

/mjt

Re: BSD disklabel and autodetection

[Neil Brown]

On Monday July 29, mjt@tls.msk.ru wrote:
> martin@hack.org wrote:
> > 
> []
> > following some hints i've seen elsewhere on the list i tried to pass md
> > parameters to the kernel ->
> > 
> > Booting on Nautilus using machine vector Nautilus from SRM
> > Command line: ro root=/dev/md1 md=1,/dev/sdb5,/dev/sdc2,/dev/sdd2 raid=noautodetect
> > md: Will configure md1 (super-block) from /dev/sdb5,/dev/sdc2,/dev/sdd2, below.
> > 
> > with the raid=noautodetect option it works.
> > 
> > what other raid/md options can be passed this way? and how do i configure
> > more than one device? geez, hope there's not a 256 char limit to the
> > command line...
> 
> You may use md=N,dev1,dev2,... option as many times as you want, i.e.
> 
>  linux root=... md,1=/dev/sda1,.. md=2,/dev/sda2,...
> 
> I think that it's sufficient to tell it about only ONE member of
> an array this way if your raid device has persistent superblock
> (kernel will read superblock from first disk (or second for that
> matter - if you choose to tell it about second disk) and read
> other devices from there).

Nope.  You have to list all component devices.  (Storing device
identification in the superblock is a bad idea that doesn't work in
general, but does in enough specific cases that people still seem to
like it).

> 
> About other options - there are only two, raid= (e.g. noautodetect)
> and md= (above) that are raid-related.
> 
> > are these options documented somewhere??
> 
> I personally looked at sources in drivers/md/ directory and got the
> above line by reading initialization functions.  Maybe it's documented
> somewhere in Documentation/... ;)

  Documentation/md.txt

Personally, I am not a big fan of autodetection at all.

I see two reasonable ways to start up the RAID array that
stores the root filesystem.

  1/ kernel parameters like:
                md=0,/dev/sda1,/dev/sdb1

  2/ use an initrd filesystem and a user-mode program that
    finds and assembles arrays based on a simple config file.

All non-root raid arrays should be assembled after boot by
a user-mode program.
I use and recommend mdadm
   http://www.cse.unsw.edu.au/~neilb/source/mdadm/

You can tell it how to recongnise parts of an array and 
it goes hunting, finds them, and assembles the array.

NeilBrown

md device stuck!

[martin]

hiya,

has anyone come across the problem of md devices getting 'stuck'?
currently, if i try to mount/umount md2, or run either raidstop or
mdadm --stop, the commands just hang and /proc/mdstat gives no indication
of anything going on. (the only way to kill the command seems to be to
SIGKILL its parent process...)

any ideas?

dope:~ # mount
/dev/md1 on / type ext2 (rw)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)

dope:~ # cat /proc/mdstat
Personalities : [raid1] [raid5]
read_ahead 1024 sectors
md2 : active raid5 sdb6[6] sdf1[5] sde1[4] sdd1[3] sdc1[2] sdb4[1] sda5[0]
      44220800 blocks level 5, 32k chunk, algorithm 2 [6/6] [UUUUUU]
md1 : active raid5 sdd2[2] sdc2[1] sdb5[0]
      17688448 blocks level 5, 32k chunk, algorithm 2 [3/3] [UUU]
md0 : active raid1 sdb2[1] sda2[0]
      2147264 blocks [2/2] [UU]
unused devices: <none>

dope:~ # ps -flw
  F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
004 S root      4414  4413  0  72   0 -   506 norita 15:33 pts/4    00:00:00 -bash
000 D root      4438  4414  0  72   0 -   220 ptrace 15:34 pts/4    00:00:00 mdadm --stop /dev/md2

many thanks,

/m

Re: md device stuck!

[Neil Brown]

On Monday July 29, martin@hack.org wrote:
> 
> hiya,
> 
> has anyone come across the problem of md devices getting 'stuck'?
> currently, if i try to mount/umount md2, or run either raidstop or
> mdadm --stop, the commands just hang and /proc/mdstat gives no indication
> of anything going on. (the only way to kill the command seems to be to
> SIGKILL its parent process...)
> 
> any ideas?

You didn't say which kernel you are running ......

> 
> dope:~ # ps -flw
>   F S UID        PID  PPID  C PRI  NI ADDR SZ WCHAN  STIME TTY          TIME CMD
> 004 S root      4414  4413  0  72   0 -   506 norita 15:33 pts/4    00:00:00 -bash
> 000 D root      4438  4414  0  72   0 -   220 ptrace 15:34 pts/4    00:00:00 mdadm --stop /dev/md2

and you don't have a correct System.map file.  There is no-way that
mdadm will be blocked in ptrace.

NeilBrown

Re: md device stuck!

[martin]

On Wed, 31 Jul 2002, Neil Brown wrote:

> You didn't say which kernel you are running ......

sorry, it's a 2.4.4 on alpha 21264

> and you don't have a correct System.map file.  There is no-way that
> mdadm will be blocked in ptrace.

you're perfectly right! fixed that, now it blocks on down_f (?!)

000 D root      4438     1  0  72   0 -   220 down_f Jul29 ?        00:00:00 mdadm --stop /dev/md2

but maybe that's a lingering problem from the previous shenanigans.
unfortunately i can't reboot the machine at the moment, but i guess these
probs will go away when i do.

think this is how it first got stuck, on umount ->

Jul 29 15:19:47 dope kernel: kernel BUG at inode.c:489!
Jul 29 15:19:47 dope kernel: umount(4290): Kernel Bug 1
Jul 29 15:19:47 dope kernel: pc = [copy_strings+272/784]  ra = [copy_strings+260/784]  ps = 0000
Jul 29 15:19:47 dope kernel: v0 = 000000000000001b  t0 = 0000000000000001  t1 = 0000000000000001
Jul 29 15:19:47 dope kernel: t2 = fffffc00009f31b0  t3 = fffffc0000a1bb08  t4 = 0000000000000000
Jul 29 15:19:47 dope kernel: t5 = fffffc00271ad0c0  t6 = 0000000000000065  t7 = fffffc00130cc000
Jul 29 15:19:47 dope kernel: a0 = 0000000000000000  a1 = 0000000000000001  a2 = 0000000000000001
Jul 29 15:19:47 dope kernel: a3 = fffffffffffffff9  a4 = 0000000000000002  a5 = 0000000000000002
Jul 29 15:19:47 dope kernel: t8 = 0000000000003fff  t9 = fffffc0000a1b3e0  t10= fffffc0000a1c890
Jul 29 15:19:47 dope kernel: t11= 000000000000000a  pv = fffffc000081d980  at = 0000000000000000
Jul 29 15:19:47 dope kernel: gp = fffffc0000a15f28  sp = fffffc00130cfdf8
Jul 29 15:19:47 dope kernel: Code: 225f01e9  lda a2,489(zero)
Jul 29 15:19:47 dope kernel:  a77da4d8  ldq pv,-23336(gp)
Jul 29 15:19:47 dope kernel:  6b5b663f  jsr ra,(pv)
Jul 29 15:19:47 dope kernel:  27ba001b  ldah gp,27(ra)
Jul 29 15:19:47 dope kernel:  23bde9d4  lda gp,-5676(gp)
Jul 29 15:19:47 dope kernel:  00000081  call_pal 129
Jul 29 15:19:47 dope kernel: *a44901c8  ldq t1,456(s0)
Jul 29 15:19:47 dope kernel:  44421001  and t1,16,t0
Jul 29 15:19:47 dope kernel:
Jul 29 15:19:47 dope kernel: Trace:          86769c           8678ac           852934           852f28           8530a8           810a80


assuming linux/fs/inode.c, here's the context:

/**
 * clear_inode - clear an inode
 * @inode: inode to clear
 *
 * This is called by the filesystem to tell us
 * that the inode is no longer useful. We just
 * terminate it with extreme prejudice.
 */
void clear_inode(struct inode *inode)
{
        invalidate_inode_buffers(inode);

        if (inode->i_data.nrpages)
                BUG();
        if (!(inode->i_state & I_FREEING))
line 489 ->>>   BUG();
        if (inode->i_state & I_CLEAR)
                BUG();
        wait_on_inode(inode);
        if (IS_QUOTAINIT(inode))
                DQUOT_DROP(inode);
        if (inode->i_sb && inode->i_sb->s_op &&
inode->i_sb->s_op->clear_inode)
                inode->i_sb->s_op->clear_inode(inode);
        if (inode->i_bdev) {
                bdput(inode->i_bdev);
                inode->i_bdev = NULL;
        }
        inode->i_state = I_CLEAR;
}



/m