From: Kevin Corry <kevcorry@us.ibm.com>
To: Wakko Warner <wakko@animx.eu.org>
Cc: Scott Long <scott_long@adaptec.com>, linux-kernel@vger.kernel.org
Subject: Re: Proposed enhancements to MD
Date: Wed, 14 Jan 2004 10:16:09 -0600 [thread overview]
Message-ID: <200401141016.09361.kevcorry@us.ibm.com> (raw)
In-Reply-To: <20040113183806.A16839@animx.eu.org>
On Tuesday 13 January 2004 17:38, Wakko Warner wrote:
> > > As I've understood it, the configuration for DM is userspace and the
> > > kernel can't do any auto detection. This would be a "put off" for me
> > > to use as a root filesystem. Configurations like this (and lvm too
> > > last I looked at it) require an initrd or some other way of setting up
> > > the device. Unfortunately this means that there's configs in 2
> > > locations (one not easily available, if using initrd. easily !=
> > > mounting via loop!)
> >
> > You can always do the following: use a mini root fs on the partition
> > where the kernel is located that does nothing but vgscan and friends and
> > then calls pivot_root. '/sbin/init' of the mini root fs looks like:
>
> What is the advantage of not putting the autodetector/setup in the kernel?
Because it can be incredibly complicated, bloated, and difficult to coordinate
with the corresponding user-space tools.
> Not everyone is going to use this software (or am I wrong on that?) so that
> can be left as an option to compile in (or as a module if possible and if
> autodetection is not required). How much work is it to maintain something
> like this in the kernel?
Enough to have had the idea shot down a year-and-a-half ago. EVMS did
in-kernel volume discovery at one point, but the driver was enormous. Let's
just say we finally "saw the light" and redesigned to do user-space
discovery. Trust me, it works much better that way.
> I like the fact that MD can autodetect raids on boot when compiled in, I
> didn't like the fact it can't be partitioned. That's the only thing that
> put me off with MD. LVM put me off because it couldn't be auto detected at
> boot. I was going to play with DM, but I haven't yet.
I guess I simply don't understand the desire to partition MD devices when
putting LVM on top of MD provides *WAY* more flexibility. You can resize any
volume in your group, as well as add new disks or raid devices in the future
and expand existing volumes across those new devices. All of this is quite a
pain with just partitions.
And setting up an init-ramdisk to run the tools isn't that hard. EVMS even
provides pre-built init-ramdisks with the EVMS tools which has worked for
virtually all of our users who want their root filesystem on an EVMS volume.
It really is fairly simple, and I run three of my own computers this way. If
you'd like to give it a try, I'd be more than happy to help you out.
--
Kevin Corry
kevcorry@us.ibm.com
http://evms.sourceforge.net/
next prev parent reply other threads:[~2004-01-14 16:18 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-13 0:34 Proposed enhancements to MD Scott Long
2004-01-13 16:26 ` Jakob Oestergaard
[not found] ` <20040113201058.GD1594@srv-lnx2600.matchmail.com>
2004-01-14 19:07 ` Jakob Oestergaard
[not found] ` <20040114194052.GK1594@srv-lnx2600.matchmail.com>
2004-01-14 21:02 ` Jakob Oestergaard
[not found] ` <20040114222447.GL1594@srv-lnx2600.matchmail.com>
2004-01-15 1:42 ` Jakob Oestergaard
2004-01-13 18:21 ` mutex
2004-01-13 19:05 ` Jeff Garzik
2004-01-13 19:30 ` mutex
2004-01-13 19:43 ` Jeff Garzik
2004-01-13 20:00 ` mutex
2004-01-13 20:44 ` Scott Long
2004-01-13 18:44 ` Jeff Garzik
2004-01-13 19:01 ` John Bradford
2004-01-13 19:41 ` Matt Domsch
2004-01-13 22:10 ` Arjan van de Ven
2004-01-16 9:31 ` Lars Marowsky-Bree
2004-01-16 9:57 ` Arjan van de Ven
2004-01-13 20:41 ` Scott Long
2004-01-13 22:33 ` Jure Pečar
2004-01-13 22:44 ` Scott Long
2004-01-13 22:56 ` viro
2004-01-14 15:52 ` Kevin Corry
2004-01-13 22:42 ` Luca Berra
2004-01-13 22:06 ` Arjan van de Ven
2004-01-13 22:44 ` Wakko Warner
2004-01-13 22:34 ` Arjan van de Ven
2004-01-13 23:09 ` Andreas Steinmetz
2004-01-13 23:38 ` Wakko Warner
2004-01-14 16:16 ` Kevin Corry [this message]
2004-01-14 16:53 ` Kevin P. Fleming
2004-01-14 23:07 ` Neil Brown
2004-01-15 21:52 ` Matt Domsch
2004-01-16 9:24 ` Lars Marowsky-Bree
2004-01-16 13:43 ` Matt Domsch
2004-01-16 13:56 ` Lars Marowsky-Bree
2004-01-16 14:06 ` Christoph Hellwig
2004-01-16 14:11 ` Matt Domsch
2004-01-16 14:13 ` Christoph Hellwig
[not found] <40036902.8080403@adaptec.com>
2004-01-13 14:19 ` Proposed Enhancements " Matt Domsch
2004-01-13 17:13 ` Andreas Dilger
2004-01-13 22:26 ` Andreas Dilger
2004-01-13 18:19 ` Kevin P. Fleming
2004-01-13 18:19 ` Jeff Garzik
2004-01-13 20:29 ` Chris Friesen
2004-01-13 20:35 ` Matt Domsch
2004-01-13 21:10 ` Matt Domsch
2004-01-13 19:59 Proposed enhancements " Cress, Andrew R
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200401141016.09361.kevcorry@us.ibm.com \
--to=kevcorry@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=scott_long@adaptec.com \
--cc=wakko@animx.eu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).