linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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/


  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).