Re: [Evms-devel] Re: [Evms-announce] EVMS announcement

Re: [Evms-devel] Re: [Evms-announce] EVMS announcement

[Mike Diehl]

On Tuesday 05 November 2002 08:55 pm, you wrote:
     > 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.

Good.  I'm beginning to feel better already.

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

<giant exhale>

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

I'm beginning to relize this.  Just a bit thick skulled at the moment.

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

That was a cheep shot on my part.  But one thing that sets Linux apart from, 
say, FreeBSD, is that linux tends to have all of the features that USERS 
want.  I'm able to use my linux box as a firewall, IDS, DBMS, file server... 
etc.  But my AIX friends keep pointing at Volume Management and saying, "you 
can't do this...."  And indeed, with LVM, I couldn't when I tried.  I once 
lost a 360Gb database because I tried to resize it.  So call me sensitve.

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

I'm beginning to see some logic to this.  Remember, I've only been thinking 
about this for a few hours.  It sounds like the EVMS team has been thinking 
about it for quite some time.  I may have over-reacted.

-- 
Mike Diehl
PGP Encrypted E-mail preferred.
Public Key via: http://dominion.dyndns.org/~mdiehl/mdiehl.asc

Re: [Evms-devel] Re: [Evms-announce] EVMS announcement

[Steve Pratt]

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

Re: [Evms-devel] Re: [Evms-announce] EVMS announcement

[Alan Cox]

On Wed, 2002-11-06 at 09:34, Hendrik Visage wrote:
> On Wed, Nov 06, 2002 at 12:21:20AM +0000, Alan Cox wrote:
> > On Tue, 2002-11-05 at 21:11, Mike Diehl wrote:
> > > 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.  
> > 
> > Thats a seperate issue in the pile. You might want to do things like
> > 
> > 			lvm2 volumes
> 
> Quick question Alan: Are you saying that EVMS can't do this ??

The "one driver" model doesnt scale to it sanely. The EVMS tools
certainly can

Re: [Evms-devel] Re: [Evms-announce] EVMS announcement

[Hendrik Visage]

On Wed, Nov 06, 2002 at 12:21:20AM +0000, Alan Cox wrote:
> On Tue, 2002-11-05 at 21:11, Mike Diehl wrote:
> > 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.  
> 
> Thats a seperate issue in the pile. You might want to do things like
> 
> 			lvm2 volumes

Quick question Alan: Are you saying that EVMS can't do this ??

Hendrik

>                              |
>                            RAID-5
>                        /  |  \   \
>                     4 encrypted volumes with different keys
>                        |      |         |        |
>                              4 NBD disk volumes over TCP
> 			    (or 4 iSCSI volumes)
> 
>                      4 physical disks in different jurisdictions
> 
> 
> (and the physical disks or iscsi volumes might in fact be over lvm2 on
> the othe end - its all a lot more modular than just volume management at
> least at the kernel level - tools is different)
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Evms-devel mailing list
> Evms-devel@lists.sourceforge.net
> To subscribe/unsubscribe, please visit:
> https://lists.sourceforge.net/lists/listinfo/evms-devel