RE: 3 questions...

RE: 3 questions...

[Shaw, Marco]

> > tell kernel which devices to use for your root filesystem (if your 
> > root is on raid device), by using something like
> >   append="md=2,/dev/hda1,/dev/hdb1"
> 
> I have some partitions with the fd type in raid arrays but 
> would like to switch to the manual method you just described. 
> These partitions hold data I care about. Is it safe to change 
> the partition type:
>    - while the array is not active?
>    - while the array is active?

I would recommend to umount the array and stop it if you can.  The fd or default 83 (IIRC), is just a label on the disk, and won't destroy data.  I've more experience with labels on Solaris, and have done those "on-the-fly" with no affects though.

Remember (with RedHat Advanced Server anyway), you'd have to actually disable autodetection.  I'm still working on how it works because I'm still unclear whether this is a kernel feature, or just a result of init scripts.  An older RedHat reference:
http://www.redhat.com/support/resources/tips/raid/RAID-4.html

Marco

Re: 3 questions...

[Michael Tokarev]

Shaw, Marco wrote:
[]
> Remember (with RedHat Advanced Server anyway), you'd have to actually disable autodetection.  I'm still working on how it works because I'm still unclear whether this is a kernel feature, or just a result of init scripts.  An older RedHat reference:
> http://www.redhat.com/support/resources/tips/raid/RAID-4.html

Autodetection works in kernel, before kernel tries to
mount root filesystem.  At this time, kernel looks at
all partitions of type "raid autodetect" to see if this
is a part of an array, and brings up all it can find
(In fact, this seems to be not true sisnce at least on
2.2 here, only root mddev is started while another two
also marked as "autodetect").  The rest is done in
initscripts, after root filesystem gets mounted (kernel
has no clue about initscripts at all).

/mjt

3 questions...

[Shaw, Marco]

1. When using fdisk, is it really required (or a "good idea") to create the partitions as type "fd"?  I've typically just created a regular Linux partition, and would let mkraid to it's thing.  (As a result, it seems strange that I ran into #2 below since I didn't do this step of changing the type.)

2. I can't seem to find a document describing how software RAID really works technically.  (Yes, I could read the source, but I'm not the most proficient C person, nor do I want to work all weekend looking at the source either.)  I had a problem the other day, where I had a md0 device that the system was not able to mount (logical disks mounted from a SAN).  Because the system could not mount the disks, it would fail to boot at the section where the system would attempt to auto-detect md0 and would drop me to single-user mode type prompt.

Taking the directory out of fstab, and tried to find something in /etc/rc.d/init.d that was trying to do stuff with the md devices at boot but couldn't find anything.  Ended up being a problem with an old modular driver, and had to create a new initrd with an updated driver, but I was stuck for a second (well more than a second really).

3. Is "persistent-superblock" supported with Linear and RAID0?  I think chunk-size is only supported in RAID0 and higher, but Linear will just skip the configuration with an informational warning at boot.

Marco

PS Basing some of my assumptions/statements above from the Software-RAID HOWTO v. 0.90.7.

Re: 3 questions...

[Michael Tokarev]

Shaw, Marco wrote:
> 1. When using fdisk, is it really required (or a "good idea") to
 > create the partitions as type "fd"?  I've typically just created
 > a regular Linux partition, and would let mkraid to it's thing.

No.  Raid code will happily use any partition type you'll specify.
Partition type "fd" stands for "raid AUTODETECT" - that is, at
bootup, kernel looks at your partitions of this type (if any)
to automatically bring up an array that may be required for your
root filesystem.  But instead of guessing, it is better IMHO to
just tell kernel which devices to use for your root filesystem
(if your root is on raid device), by using something like
  append="md=2,/dev/hda1,/dev/hdb1"
in your lilo.conf or similar (to mean bring up /dev/md2 consisting
of /dev/hda1 and /dev/hdb1 - you should got an idea).
Non-root arrays may be set up just easily from your real root
filesystem.  In either way, do not bother using "fd" partition
type for non-automatically-started-root-fs device.  For me,
I don't use autodetect at all since it will be a PITA if I'll
need to insert drives from one machine to another - on another
machine I may get just unpredictable results after kernel will
try to bring up autodetected raid arrays from both own disks
and disk from foreign machine (btw, it will be nice to DISABLE
raid autodetection completely for this very reason, as it was
possible on 2.2 kernels).

 > (As a result, it seems strange that I ran into #2 below since I
 > didn't do this step of changing the type.)
> 
> 2. I can't seem to find a document describing how software RAID
 > really works technically.  (Yes, I could read the source, but I'm
 > not the most proficient C person, nor do I want to work all weekend
 > looking at the source either.)  I had a problem the other day,
 > where I had a md0 device that the system was not able to mount
 > (logical disks mounted from a SAN).  Because the system could not
 > mount the disks, it would fail to boot at the section where the
 > system would attempt to auto-detect md0 and would drop me to
 > single-user mode type prompt.

An array should be started before it can be mounted (that should
be obvious, right?).  You may got single-user prompt *only* if
your root filesystem was mounted successefully (or else you'd
got kernel panic instead).  So, an answer is in your startup
scripts -- there should be a script that brings raid arrays
up before mounting filesystems, and there should be some file
where an information about how to assemble arrays is stored
(maybe /etc/raidtab or /etc/mdadm.conf).  But this highly
depends on distribution you use, and I can't help you here.

> Taking the directory out of fstab, and tried to find something
 > in /etc/rc.d/init.d that was trying to do stuff with the md
 > devices at boot but couldn't find anything.  Ended up being
 > a problem with an old modular driver, and had to create a new
 > initrd with an updated driver, but I was stuck for a second
 > (well more than a second really).
> 
> 3. Is "persistent-superblock" supported with Linear and RAID0?
 > I think chunk-size is only supported in RAID0 and higher, but
 > Linear will just skip the configuration with an informational
 > warning at boot.

I think persistent-superblocks are supported with all raid levels,
but I may be wrong.  At least, raid0 has this feature for sure.

/mjt

Re: 3 questions...

[Florent Rougon]

Hi,

Michael Tokarev <mjt@tls.msk.ru> wrote:

> No.  Raid code will happily use any partition type you'll specify.
> Partition type "fd" stands for "raid AUTODETECT" - that is, at

[...]

> root filesystem.  But instead of guessing, it is better IMHO to
> just tell kernel which devices to use for your root filesystem
> (if your root is on raid device), by using something like
>   append="md=2,/dev/hda1,/dev/hdb1"

I have some partitions with the fd type in raid arrays but would like to
switch to the manual method you just described. These partitions hold
data I care about. Is it safe to change the partition type:
   - while the array is not active?
   - while the array is active?

Thanks.

-- 
Florent

Re: 3 questions...

[Michael Tokarev]

Florent Rougon wrote:
[]
> I have some partitions with the fd type in raid arrays but would like to
> switch to the manual method you just described. These partitions hold
> data I care about. Is it safe to change the partition type:
>    - while the array is not active?
>    - while the array is active?

Hmm, it's always a good idea to have a backup handy, just in
case, right? ;)

Kernel code does not care about partition table _at all_ while
disk is in use - kernel reads partition table when disk usage
goes from 0 to 1, and keeps that table in memory after that, so
you may do with your partitions *anything* you like (incl. erasing
the whole table) while it's in use (but do not forget to restore
things before next reboot ;).  Concerning changing partition type,
well - having an accurate tool for this, it shuld be safe (an
operation is very simple, just changing one byte in disk's partition
table (an area that isn't used for anything else)).  So, answer
to both your question is yes, but see my first statement (in
fact, it is NOT completely safe to do ANYTHING at all with your
data - kernel may screw up and write random garbage to your
disks just at any time, even if you told it to mount a filesystem
read-only -- and disk may crash at random... ;).  Oh well... ;)
(don't panic, however - that's quite normal!.. ;)

/mj

Re: 3 questions...

[Florent Rougon]

Michael Tokarev <mjt@tls.msk.ru> wrote:

> Hmm, it's always a good idea to have a backup handy, just in
> case, right? ;)

Oh, yes.

> Kernel code does not care about partition table _at all_ while
> disk is in use - kernel reads partition table when disk usage
> goes from 0 to 1, and keeps that table in memory after that, so

[...]

> table (an area that isn't used for anything else)).  So, answer
> to both your question is yes, but see my first statement (in

[...]

Thank you very much for this detailed answer.

-- 
Florent