On Wednesday June 14, [EMAIL PROTECTED] wrote:
>
> On Wed, 14 Jun 2000, Neil Brown wrote:
>
> > Indeed, initrd is the way I would like to go, but it probably needs to
> > be made or simple/turn-key first.
>
> initrd is much more capable than the kernel's command line. The kernel
> command line is limited to 80 characters - which is awfully few. We do
> _NOT_ want to put device configuration information in that line. (even if
> LILO could handle all 256 characters, that would not be enough in eg. a
> 64-disk installation.) MD_BOOT is very limited and conceptually misplaced.
Your example of a 64-disk installation seems odd. I would only ever
consider using MD_BOOT or AUTODETECT or initrd to configure the device
which holds the root filesystem. Everything else should happen once
the real root filesystem is up and running. Then you can have your
mechanisms for finding and configuring RAID arrays in user-space where
they below.
And having a 64 disk root filesystem seems ill-advised.
>
> > Until then, device names can work for finding the parts of RAID just a
> > well as they can work for finding a root filesystem.
>
> certain device names (such as /dev/md0) are 'persistent' (unless
> reconfigured explicitly by the system administrator). So if the boot
> device is /dev/md0 then it's resistent wrt. disk failures. This way if all
> devices are RAID devices then the system is completely shielded from the
> problem of device-name changes. The only case where 'external' device
> names are used is the case adding a new device to the 'RAID domain'.
But not necessarily resilient to a new device being added which
happens to get found earlier than some pre-existing device, and which
has a RAID super block which confused the interpretation of
devices/partitions that are found later.
>
> > I don't insist you use my prefered method, why do you insist that I
> > use yours?
>
> well, i gave you reasons why MD_BOOT is a kludge (and why autostart is
> offering all the benefits of MD_BOOT but has none of the shortcomings),
> and i (hope) to have explained the conceptual reasons behind autostart
> partitions. In Linux we do phase out kludges over time. Your email does
> not address this argument. Give me one example of a boot situation that
> cannot be handled with autostart. Give me a reason why we should keep an
> less capable subset of a feature (ie. MD_BOOT) in a confusing way. "just
> because i prefer it" is not a very technical answer. [there might be
> reasons i have not considered yet - please share them with us.]
>
> Ingo
Ok, one of my goals is to build a number of servers (a mail server, an
NFS server, probably some others) based on Linux and with mirrored
"boot disks".
The master discs on each of the first two IDE controlers would be
mirrored and hold the root filesystem and swap and probably something
else.
I would like these two discs to be mirrored as discs, not as multiple
partitions.
While I can certainly see the value in build RAID arrays out of
partitions, it is much cleaner to me to build them out of drives.
The md0 which is a RAID-1 of /dev/hda and /dev/hdb would be
partitioned into md0a (or mda1 or md0p1 or ..) for root, and md0b for
swap etc.
I would also like to be completely confidant that if I loose a machine
and need to pull discs/controllers out of one and put them in another
to recover data, that the kernel wont try to build raid arrays out of
discs without me explicitly telling it to.
Now, it's true that you cannot partitions md devices yet, but I don't
think it should be an insurmountable problem and I think it would be
quite useful, and I plan to do it (eventually).
Depending on autodetect causes two problems in the above scenario.
1/ disc drives don't have partition types, only partitions do, so you
couldn't create a RAID out of discs.
2/ if I pull drives out of one machine and plug them into another, the
kernel will make decisions about what RAID devices to configure before
I get a prompt at which to tell it otherwise.
So I think that AUTO_DETECT is just as much of a kludge as MD_BOOT.
Neither are perfect, but both have their uses, and an effective initrd
strategy could, and should, replace them both (one day).
Just to make point 2 very clear, suppose I have two similar machines
each with a mirrorer pair of drives, each configured to present the
boot partition as md0. One dies so to restore data I pull the drives
out and plug them in as slaves on the two IDE busses in the working
computer.
Now suppose further that restoring data would be much easier if I could
boot up as the other computer, not just boot and mount the other
computers drives (I cannot give you a for-instance, but it isn't too
far fetched).
With autodetect, I cannot boot off the second pair without disabling
one of the first pair, so alternately booting as one or the other
would be awkward.
If I could at that point disable autodetect (had I turned it on) and
use md_boot to explicitly tell the kernel what I want where, it would
be much more manageable.
NeilBrown
