Re: early userspace and volume management
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/