early userspace and volume management

[Bill Rugolsky Jr.]

Back in January I started packaging up Device-Mapper, and LVM2, and
made some changes to initscripts, mkinitrd, etc., to get root-on-lvm2.
Now that device-mapper is stabilizing, I'd like to take up this task
again and contribute the changes to Fedora core.  Before doing so,
I'd like to solicit some feedback on how to proceed with changes to
early userspace.

1.  nash is inadequate to the task.  Replacing it with a real shell
    and other tools will take us over the size limit for
    a floppy.  Does it matter any more?  A kernel with ACPI won't fit
    on a floppy either, and we are going to want to include a lot of
    userland discovery code in initramfs as we move into 2.7.

    Once we exceed the size of a floppy, is there another "natural"
    size constraint that would prevent just using the usual tools, such
    as mdadm, perhaps in a multi-call binary or rebuilt against klibc?

2.  People are going to use various combinations of MD, Device-Mapper,
    LVM2, and EVMS2.  Do we want to support the simultaneous, stacked
    use of all of these?  Is that too complicated, and should, e.g.,
    (LVM2+dmsetup) and EVMS2 be mutually exclusive?  One of the nicest
    features of EVMS2 is the support for legacy partitions.  This can
    also be done with dmsetup and some scripting, or by generalizing LVM2.

3.  We currently lack any infrastructure for reconfiguration in early
    userspace.  There are numerous maintenance tasks that require that
    a resource be taken offline, e.g., repartitioning, or shrinking a
    filesystem.  I am currently working on scripts to do a system upgrade
    (repartition, etc.) on a RAID1 system with minimal downtime by (a)
    breaking the mirror, (b) upgrading the detached half, (c) reboot
    using the upgraded system image, and (d) resyncing the mirror.
    One could as well imagine support for pulling a new system image
    from a server.  Ideally, there would be infrastructure to just drop
    in early userspace scripts.  Initramfs makes this easy, because one
    can just append a cpio archive with the required files.

4.  Volume management is just one of many tasks that need attention
    in early userspace.  Is there a roadmap anywhere?

Any thoughts or pointers to works-in-progress would be appreciated.

Regards,

	Bill Rugolsky

[Michael K. Johnson]

On Fri, Oct 10, 2003 at 02:29:02PM -0400, Bill Rugolsky Jr. wrote:
>  Back in January I started packaging up Device-Mapper, and LVM2, and
>  made some changes to initscripts, mkinitrd, etc., to get root-on-lvm2.
>  Now that device-mapper is stabilizing, I'd like to take up this task
>  again and contribute the changes to Fedora core.  Before doing so,
>  I'd like to solicit some feedback on how to proceed with changes to
>  early userspace.
>  
>  1.  nash is inadequate to the task.  Replacing it with a real shell
>      and other tools will take us over the size limit for
>      a floppy.  Does it matter any more?  A kernel with ACPI won't fit
>      on a floppy either, and we are going to want to include a lot of
>      userland discovery code in initramfs as we move into 2.7.
>  
>      Once we exceed the size of a floppy, is there another "natural"
>      size constraint that would prevent just using the usual tools, such
>      as mdadm, perhaps in a multi-call binary or rebuilt against klibc? 
For 2.6 kernels, where (with ACPI) it just isn't going to fit on a
floppy anyway, I see no problems with this approach.

An open question is, I guess, whether we want to fork mkinitrd --
should it stick to nash for 2.4 kernels where the possibility of
fitting on a floppy still remains?  I'd think that for early work,
being able to move back and forth between 2.4 and 2.6 kernels
would be valuable, and people would complain about regressions
if mkinitrd lost the ability to make floppies on 2.4 kernels that
would otherwise support them.

However, there are multiple ways to achieve that goal; if keeping
full support for the 2.4 way of doing things in the same script
with the best new methods for 2.6 makes the script harder to read,
it's easy to do a version check early on and exec mkinitrd-2.4
(or whatever) as a separate script.  That would make it easy to
keep the two separate if it's useful to do so.

>  2.  People are going to use various combinations of MD,
> Device-Mapper,
>      LVM2, and EVMS2.  Do we want to support the simultaneous, stacked
>      use of all of these?  Is that too complicated, and should, e.g.,
>      (LVM2+dmsetup) and EVMS2 be mutually exclusive?  One of the nicest
>      features of EVMS2 is the support for legacy partitions.  This can
>      also be done with dmsetup and some scripting, or by generalizing LVM2. 
Right, there are two conflicting goals:
 o  All reasonable stacking should be supported.
 o  Adding options that don't really increase functionality is just
    asking for more bugs.  :-)

I do hear some nice things about EVMS2, and their philosophy of
making everything Just Work[tm] with a consistent interface is
attractive.  However, I'm worried about throwing babies out with
bathwater; for instance, mdadm is a really nice way to deal with
the md layer (like its hot spare migration and monitoring
capabilities).

This clearly needs lots of discussion, and I have more questions
than answers right now.  Probably could use a bit of experimentation,
too.

>  4.  Volume management is just one of many tasks that need attention
>      in early userspace.  Is there a roadmap anywhere? 
Right, there are lots of things that need re-thinking for early
userspace.  I'm not aware of a formal roadmap document, if that's
what you mean.

Basically, I see two things here: we need to preserve the functionality
of people's existing installations, but we've really got a good
opportunity to make radical changes to the mechanism to make it more
sane and easier to maintain, blah blah blah...

We haven't written up a detailed proposal within Red Hat for precisely
what we want to do here; rather, we've got several people on the kernel
team who have done significant work on early user space (e.g. Al and
Jeff) because we recognize that it's an important change to make, and
will enable all sorts of improvements.

michaelkjohnson

 "He that composes himself is wiser than he that composes a book."
 Linux Application Development                     -- Ben Franklin
 http://people.redhat.com/johnsonm/lad/