mdadm and raidtools

[Jeremy Katz]

On Thu, 2004-01-15 at 09:14 -0500, Bill Rugolsky Jr. wrote:
> On Wed, Jan 14, 2004 at 05:22:22PM -0500, Jeremy Katz wrote:
> > On Wed, 2004-01-14 at 10:22 -0500, Bill Rugolsky Jr. wrote:
> > > With mdadm support in initscripts (and soon initrd, I hope), it would
> > > not be terribly difficult to do this in Fedora. 
> > 
> > initrds currently just call the RAID autostart ioctl from within nash.
> > Switching to mdadm here is going to make things a bit larger :/
>  
> I know.  That's why doing a live upgrade is a bit of a hassle. :-/

No, there are more things that make live upgrades a hassle.  eg, you're
going to need to upgrade rpm before you can upgrade other things (so
that you have an rpm that's capable of setting file contexts) but the
new rpm might end up depending on a newer glibc ... and things spiral
poorly from there.

> At this point, what fraction of users realistically are going to have a
> kernel+early userspace (initrd or initramfs) config that fits on a floppy?
> What fraction of users can't boot from a rescue CD?  Many systems don't
> even have a floppy drive anymore.

The very basic IDE disks case still fits on a floppy.  And that's still
the vast majority of users for right now.  I'd like to kill floppies
more than anyone, but everytime it gets mentioned there's a pretty large
outcry.  See a number of previous threads on the subject.

> nash made a lot of sense when the common kernel config could be
> shoe-horned onto a floppy disk with a small libc.  At this point,
> I'm inclined to use something like busybox + the full tools, compiled
> against a lightweight libc: klibc, uClibc, or dietlibc.  That would
> include things like mdadm, lvm2/evms, udev, etc.

To some extent this is done...  I don't necessarily see the value in
switching from nash to busybox, though, in cases where nash already
works.  lvm2 gets compiled against dietlibc to create /sbin/lvm.static
which is what then gets copied into the initrd.  How much of udev is
going to need to go in to initrds, I'm not quite clear on yet.

[snip]
> I'd like a mechanism to modify early userspace by:
[snip]

I'm not convinced this is the right approach.  Although flexibility is a
good thing, too much flexibility is a bad thing.  I'd rather continue to
extend mkinitrd with small, logical changes than go and overengineer a
completely new way of doing things.

Cheers,

Jeremy