mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Steve Pratt" <slpratt@us.ibm.com>
To: Mike Diehl <mdiehl@dominion.dyndns.org>
Cc: "Kevin M Corry" <corryk@us.ibm.com>,
	evms-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [Evms-devel] Re: [Evms-announce] EVMS announcement
Date: Tue, 5 Nov 2002 19:55:07 -0600	[thread overview]
Message-ID: <OFCC91E1D2.FC7FCB3C-ON05256C69.0001DCF6@pok.ibm.com> (raw)


Mike Diehl wrote:
>Well, I'm a bit disapointed.  My experience with LVM has been nothing
>short of disasterous; EVMS looked like a very good alternative to LVM.
>Volume Management is one of the FEW things that Linux lacks that the
>"Big Boys" have.

>The biggest thing that EVMS had going for it was it's modular design.  As
I
>understand it, EVMS could even be used to manage the current MD and LVM
>drivers.  I was looking forward to partition-level encryption, etc.

Let me take a minute to reiterate: EVMS is not going away and has not
given up on any of it's original goals.  EVMS will still use a plug-in
architecture in the user space tools (Engine) to coordinate across
different types of kernel volume management drivers.  You will still
be able to use EVMS to partitions disks, create MD RAID arrays,
add these arrays to LVM containers, create regions and volumes and
mkfs your filesystems and a whole lot more, all from the EVMS
interface you know and love.


>I wish the decision had gone the other way.  Get rid of LVM and get EVMS
into
>the mainstream.  Any chance that, after this "migration," we might do just
>that?

Could happen, but don't hold your breath.

>I'd love to see the day when LVM and MD aren't kernel options by
>themselves, but rather options under EVMS, along with lots of other cools
>things.

Sure, why not.  EVMS can manage both and can be expanded to manage other
device types as well.

>But never mind me.  I'm just a linux user, not a linux developer.

But users matter!!!  If we get the migration right (and we will) the only
thing
you will notice different with EVMS are the kernel config options and the
ramdisk /ramfs stuff.  Everything else should look and fell and work
exactly
the same from a user's point of view.

Steve





             reply	other threads:[~2002-11-06  0:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-06  1:55 Steve Pratt [this message]
2002-11-06  1:29 ` Mike Diehl
  -- strict thread matches above, loose matches on Subject: below --
2002-11-05 22:19 Kevin Corry
2002-11-05 21:00 ` [Evms-announce] " Mike Diehl
2002-11-05 21:11   ` Mike Diehl
2002-11-06  0:21     ` Alan Cox
2002-11-06  9:34       ` [Evms-devel] " Hendrik Visage
2002-11-06 13:55         ` Alan Cox

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=OFCC91E1D2.FC7FCB3C-ON05256C69.0001DCF6@pok.ibm.com \
    --to=slpratt@us.ibm.com \
    --cc=corryk@us.ibm.com \
    --cc=evms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mdiehl@dominion.dyndns.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

all inboxes | Powered by JetHome®