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

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

[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

EVMS announcement

[Kevin Corry]

Greetings EVMS users,

On behalf of the EVMS team, we would like to announce a significant change
in direction for the Enterprise Volume Management System project.

As many of you may know by now, the 2.5 kernel feature freeze has come
and gone, and it seems clear that the EVMS kernel driver is not going
to be included. With this in mind, we have decided to rework the EVMS
user-space administration tools (the Engine) to work with existing
drivers currently in the kernel, including (but not necessarily limited
to) device mapper and MD.

Why make this change? With EVMS being passed over for inclusion in 2.5,
the future of the EVMS kernel driver becomes very uncertain. We could
obviously continue working on it and keep it up-to-date as a patch
against the latest kernels. Numerous helpful comments and changes were
suggested during the review of the code last month on the kernel mailing
list. We could spend the time to make many of the desired fixes,
including some architectural and interface changes. However, the one
issue that has not been addressed at length is EVMS's in-kernel volume
discovery mechanism.  We believe that even if the other changes are
made, this will eventually become an issue at a later time. Moving
discovery to user-space is certainly a possibility. However, at that
point, it would become difficult to differentiate the EVMS driver from
the device mapper driver, since they would be performing very similar
tasks.

In addition, there would be no need to maintain duplicate MD kernel
code in order to provide compatibility with existing software RAID
devices.  Obviously this duplication has been a significant issue, but
it was an unfortunate necessity in order for MD devices to be discovered
within the current EVMS kernel framework. With discovery moving to
user-space, the EVMS tools can simply be rewritten to communicate with
the existing MD driver in the kernel. This approach allows MD to be used
directly, without requiring it to be immediately ported to device mapper.
However, if the decision is made in the future to make that port, then
the EVMS tools should only become simpler.

We will also emphasize that this change has not been made suddenly or
without a great deal of thought. We have been contemplating this
possibility since shortly after the Ottawa Linux Symposium in July.
However, we continued to develop the EVMS kernel driver because of
input from our users. We wanted to go ahead and submit the driver and
get the opinion of the full community before making this decision. In
the last few weeks it has become clear that the current EVMS approach
is not what the kernel community was looking for, so we have spent that
time determining the feasibility and consequences of making this switch.
We have come up with a good initial plan, and everyone involved now
agrees that this is the best course of action.

So how will this switch affect the EVMS users? Ideally, we want the
users' experience with EVMS to remain completely unchanged. Based on
our current plans, the user interfaces will not have to change at all,
since we don't see any major changes to the Engine's external
application interface. The plan is to provide the same, single,
coherent method for performing all volume management tasks. This change
will be almost transparent for most users. The same features, plugins,
and capabilities will be supported.

There will, of course, be some minor changes. Specifically, installing
EVMS will be slightly different. It will involve different kernel
options than you are used to with the current version. In the 2.5 kernel,
all of the major components are already present, so little, if any,
kernel patching should be necessary. Since device mapper has not yet
been included in the main 2.4 kernel, 2.4 users will still require kernel
patches. In addition, some functionality still does not exist in any of
the available drivers. Specifically, we may provide extra device mapper
modules for features like bad block relocation. The installation of the
EVMS engine tools, on the other hand, should not change significantly
from the current method.

The other major difference will be due to the move to user-space discovery.
First of all, why make this switch? The most obvious reason is that the
kernel drivers become much simpler, and the only things they need to
provide is I/O handling and a method for activating the volumes. While
disk partitioning and software RAID still perform discovery in the kernel,
the trend seems to be to move these tasks to user-space. It is likely at
some point in the future that partitioning and MD will also be moved out
of the kernel as well. However, the drawback to making this switch is
losing automatic boot-time volume discovery. Activating EVMS volumes will
now require a call to a user-space utility, which will need to be added to
the system's init scripts in order to activate the volumes on each boot.

In addition, this switch complicates having the root filesystem on an
EVMS volume. Currently there is a lot of work being done on adding
initramfs to the 2.5 kernel, which will provide a pre-root-fs user-space.
This new system should provide a simple method for adding tasks to run
during this early user-space, and those who wish to use root-on-EVMS will
just need to add the EVMS tools to their initramfs. For 2.4 users, this
means using an initial ramdisk (initrd) to provide this same pre-root
user-space. Initrd setup is certainly awkward and often distribution-
specific. But we will do our best to provide adequate instructions and
assistance to those who need help in that situation.

Looking ahead, we *will* continue to *fully* support the 1.2.0 version
of EVMS on 2.4 kernels, and possibly release a 1.2.1 version with some
recent bug fixes. We will also make a reasonable effort to maintain the
current EVMS kernel driver on 2.5. It will not go through any other
major changes, but we will try to keep it up-to-date and working with
the latest 2.5 releases, until the new EVMS tools are complete. At that
point, the 2.5 EVMS driver will be dropped. Also, the new enhancements
we have been working on recently, such as clustering and volume move,
will only be developed under the new Engine model, and will not be
available for the current 1.2.x code base.

So how long will this take? Currently, we are estimating that we can
have the user-space volume activation framework working, along with
initial support for most of the plugins, by early 2003. Certain features,
such as BBR and Snapshotting, may take longer to work out the details of
their operation. We will soon open a new CVS tree to hold the new Engine
code, leaving the old trees as a repository for bug fixes to the 1.2.x
version.

In summary, we feel that this decision is the best way to support our
users for the long term. We want to provide EVMS on current and future
kernels, and we feel this change provides the best method for achieving
that. At the same time, this addresses all of the concerns voiced by
the kernel community.  If anyone has any questions or concerns about
this decision, please email us or the EVMS mailing list at
evms-devel@lists.sf.net. We will be happy to answer any questions or
discuss these changes in more detail.

Thank you,

The EVMS Team
http://evms.sourceforge.net/
evms-devel@lists.sourceforge.net

Re: [Evms-announce] EVMS announcement

[Mike Diehl]

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.




On Tuesday 05 November 2002 05:19 pm, Kevin Corry wrote:
     > Greetings EVMS users,
     >
     > On behalf of the EVMS team, we would like to announce a significant
     > change in direction for the Enterprise Volume Management System
     > project.
     >
     > As many of you may know by now, the 2.5 kernel feature freeze has come
     > and gone, and it seems clear that the EVMS kernel driver is not going
     > to be included. With this in mind, we have decided to rework the EVMS
     > user-space administration tools (the Engine) to work with existing
     > drivers currently in the kernel, including (but not necessarily
     > limited to) device mapper and MD.
     >
     > Why make this change? With EVMS being passed over for inclusion in
     > 2.5, the future of the EVMS kernel driver becomes very uncertain. We
     > could obviously continue working on it and keep it up-to-date as a
     > patch against the latest kernels. Numerous helpful comments and
     > changes were suggested during the review of the code last month on the
     > kernel mailing list. We could spend the time to make many of the
     > desired fixes, including some architectural and interface changes.
     > However, the one issue that has not been addressed at length is EVMS's
     > in-kernel volume discovery mechanism.  We believe that even if the
     > other changes are made, this will eventually become an issue at a
     > later time. Moving discovery to user-space is certainly a possibility.
     > However, at that point, it would become difficult to differentiate the
     > EVMS driver from the device mapper driver, since they would be
     > performing very similar tasks.
     >
     > In addition, there would be no need to maintain duplicate MD kernel
     > code in order to provide compatibility with existing software RAID
     > devices.  Obviously this duplication has been a significant issue, but
     > it was an unfortunate necessity in order for MD devices to be
     > discovered within the current EVMS kernel framework. With discovery
     > moving to user-space, the EVMS tools can simply be rewritten to
     > communicate with the existing MD driver in the kernel. This approach
     > allows MD to be used directly, without requiring it to be immediately
     > ported to device mapper. However, if the decision is made in the
     > future to make that port, then the EVMS tools should only become
     > simpler.
     >
     > We will also emphasize that this change has not been made suddenly or
     > without a great deal of thought. We have been contemplating this
     > possibility since shortly after the Ottawa Linux Symposium in July.
     > However, we continued to develop the EVMS kernel driver because of
     > input from our users. We wanted to go ahead and submit the driver and
     > get the opinion of the full community before making this decision. In
     > the last few weeks it has become clear that the current EVMS approach
     > is not what the kernel community was looking for, so we have spent
     > that time determining the feasibility and consequences of making this
     > switch. We have come up with a good initial plan, and everyone
     > involved now agrees that this is the best course of action.
     >
     > So how will this switch affect the EVMS users? Ideally, we want the
     > users' experience with EVMS to remain completely unchanged. Based on
     > our current plans, the user interfaces will not have to change at all,
     > since we don't see any major changes to the Engine's external
     > application interface. The plan is to provide the same, single,
     > coherent method for performing all volume management tasks. This
     > change will be almost transparent for most users. The same features,
     > plugins, and capabilities will be supported.
     >
     > There will, of course, be some minor changes. Specifically, installing
     > EVMS will be slightly different. It will involve different kernel
     > options than you are used to with the current version. In the 2.5
     > kernel, all of the major components are already present, so little, if
     > any, kernel patching should be necessary. Since device mapper has not
     > yet been included in the main 2.4 kernel, 2.4 users will still require
     > kernel patches. In addition, some functionality still does not exist
     > in any of the available drivers. Specifically, we may provide extra
     > device mapper modules for features like bad block relocation. The
     > installation of the EVMS engine tools, on the other hand, should not
     > change significantly from the current method.
     >
     > The other major difference will be due to the move to user-space
     > discovery. First of all, why make this switch? The most obvious reason
     > is that the kernel drivers become much simpler, and the only things
     > they need to provide is I/O handling and a method for activating the
     > volumes. While disk partitioning and software RAID still perform
     > discovery in the kernel, the trend seems to be to move these tasks to
     > user-space. It is likely at some point in the future that partitioning
     > and MD will also be moved out of the kernel as well. However, the
     > drawback to making this switch is losing automatic boot-time volume
     > discovery. Activating EVMS volumes will now require a call to a
     > user-space utility, which will need to be added to the system's init
     > scripts in order to activate the volumes on each boot.
     >
     > In addition, this switch complicates having the root filesystem on an
     > EVMS volume. Currently there is a lot of work being done on adding
     > initramfs to the 2.5 kernel, which will provide a pre-root-fs
     > user-space. This new system should provide a simple method for adding
     > tasks to run during this early user-space, and those who wish to use
     > root-on-EVMS will just need to add the EVMS tools to their initramfs.
     > For 2.4 users, this means using an initial ramdisk (initrd) to provide
     > this same pre-root user-space. Initrd setup is certainly awkward and
     > often distribution- specific. But we will do our best to provide
     > adequate instructions and assistance to those who need help in that
     > situation.
     >
     > Looking ahead, we *will* continue to *fully* support the 1.2.0 version
     > of EVMS on 2.4 kernels, and possibly release a 1.2.1 version with some
     > recent bug fixes. We will also make a reasonable effort to maintain
     > the current EVMS kernel driver on 2.5. It will not go through any
     > other major changes, but we will try to keep it up-to-date and working
     > with the latest 2.5 releases, until the new EVMS tools are complete.
     > At that point, the 2.5 EVMS driver will be dropped. Also, the new
     > enhancements we have been working on recently, such as clustering and
     > volume move, will only be developed under the new Engine model, and
     > will not be available for the current 1.2.x code base.
     >
     > So how long will this take? Currently, we are estimating that we can
     > have the user-space volume activation framework working, along with
     > initial support for most of the plugins, by early 2003. Certain
     > features, such as BBR and Snapshotting, may take longer to work out
     > the details of their operation. We will soon open a new CVS tree to
     > hold the new Engine code, leaving the old trees as a repository for
     > bug fixes to the 1.2.x version.
     >
     > In summary, we feel that this decision is the best way to support our
     > users for the long term. We want to provide EVMS on current and future
     > kernels, and we feel this change provides the best method for
     > achieving that. At the same time, this addresses all of the concerns
     > voiced by the kernel community.  If anyone has any questions or
     > concerns about this decision, please email us or the EVMS mailing list
     > at
     > evms-devel@lists.sf.net. We will be happy to answer any questions or
     > discuss these changes in more detail.
     >
     > Thank you,
     >
     > The EVMS Team
     > http://evms.sourceforge.net/
     > evms-devel@lists.sourceforge.net
     >
     >
     > -------------------------------------------------------
     > 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-announce mailing list
     > Evms-announce@lists.sourceforge.net
     > To subscribe/unsubscribe, please visit:
     > https://lists.sourceforge.net/lists/listinfo/evms-announce

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

Re: [Evms-announce] EVMS announcement

[Mike Diehl]

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.

<pause> I got up to get a drink and my 2-year-old jumped up to my desk and 
sent this...  Continue Ranting....

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.  

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

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

     > On Tuesday 05 November 2002 05:19 pm, Kevin Corry wrote:
     >      > Greetings EVMS users,
     >      >
     >      > On behalf of the EVMS team, we would like to announce a
     >      > significant change in direction for the Enterprise Volume
     >      > Management System project.
     >      >
     >      > As many of you may know by now, the 2.5 kernel feature freeze
     >      > has come and gone, and it seems clear that the EVMS kernel
     >      > driver is not going to be included. With this in mind, we have
     >      > decided to rework the EVMS user-space administration tools (the
     >      > Engine) to work with existing drivers currently in the kernel,
     >      > including (but not necessarily limited to) device mapper and
     >      > MD.
     >      >
     >      > Why make this change? With EVMS being passed over for inclusion
     >      > in 2.5, the future of the EVMS kernel driver becomes very
     >      > uncertain. We could obviously continue working on it and keep
     >      > it up-to-date as a patch against the latest kernels. Numerous
     >      > helpful comments and changes were suggested during the review
     >      > of the code last month on the kernel mailing list. We could
     >      > spend the time to make many of the desired fixes, including
     >      > some architectural and interface changes. However, the one
     >      > issue that has not been addressed at length is EVMS's in-kernel
     >      > volume discovery mechanism.  We believe that even if the other
     >      > changes are made, this will eventually become an issue at a
     >      > later time. Moving discovery to user-space is certainly a
     >      > possibility. However, at that point, it would become difficult
     >      > to differentiate the EVMS driver from the device mapper driver,
     >      > since they would be performing very similar tasks.
     >      >
     >      > In addition, there would be no need to maintain duplicate MD
     >      > kernel code in order to provide compatibility with existing
     >      > software RAID devices.  Obviously this duplication has been a
     >      > significant issue, but it was an unfortunate necessity in order
     >      > for MD devices to be discovered within the current EVMS kernel
     >      > framework. With discovery moving to user-space, the EVMS tools
     >      > can simply be rewritten to communicate with the existing MD
     >      > driver in the kernel. This approach allows MD to be used
     >      > directly, without requiring it to be immediately ported to
     >      > device mapper. However, if the decision is made in the future
     >      > to make that port, then the EVMS tools should only become
     >      > simpler.
     >      >
     >      > We will also emphasize that this change has not been made
     >      > suddenly or without a great deal of thought. We have been
     >      > contemplating this possibility since shortly after the Ottawa
     >      > Linux Symposium in July. However, we continued to develop the
     >      > EVMS kernel driver because of input from our users. We wanted
     >      > to go ahead and submit the driver and get the opinion of the
     >      > full community before making this decision. In the last few
     >      > weeks it has become clear that the current EVMS approach is not
     >      > what the kernel community was looking for, so we have spent
     >      > that time determining the feasibility and consequences of
     >      > making this switch. We have come up with a good initial plan,
     >      > and everyone involved now agrees that this is the best course
     >      > of action.
     >      >
     >      > So how will this switch affect the EVMS users? Ideally, we want
     >      > the users' experience with EVMS to remain completely unchanged.
     >      > Based on our current plans, the user interfaces will not have
     >      > to change at all, since we don't see any major changes to the
     >      > Engine's external application interface. The plan is to provide
     >      > the same, single, coherent method for performing all volume
     >      > management tasks. This change will be almost transparent for
     >      > most users. The same features, plugins, and capabilities will
     >      > be supported.
     >      >
     >      > There will, of course, be some minor changes. Specifically,
     >      > installing EVMS will be slightly different. It will involve
     >      > different kernel options than you are used to with the current
     >      > version. In the 2.5 kernel, all of the major components are
     >      > already present, so little, if any, kernel patching should be
     >      > necessary. Since device mapper has not yet been included in the
     >      > main 2.4 kernel, 2.4 users will still require kernel patches.
     >      > In addition, some functionality still does not exist in any of
     >      > the available drivers. Specifically, we may provide extra
     >      > device mapper modules for features like bad block relocation.
     >      > The installation of the EVMS engine tools, on the other hand,
     >      > should not change significantly from the current method.
     >      >
     >      > The other major difference will be due to the move to
     >      > user-space discovery. First of all, why make this switch? The
     >      > most obvious reason is that the kernel drivers become much
     >      > simpler, and the only things they need to provide is I/O
     >      > handling and a method for activating the volumes. While disk
     >      > partitioning and software RAID still perform discovery in the
     >      > kernel, the trend seems to be to move these tasks to
     >      > user-space. It is likely at some point in the future that
     >      > partitioning and MD will also be moved out of the kernel as
     >      > well. However, the drawback to making this switch is losing
     >      > automatic boot-time volume discovery. Activating EVMS volumes
     >      > will now require a call to a user-space utility, which will
     >      > need to be added to the system's init scripts in order to
     >      > activate the volumes on each boot.
     >      >
     >      > In addition, this switch complicates having the root filesystem
     >      > on an EVMS volume. Currently there is a lot of work being done
     >      > on adding initramfs to the 2.5 kernel, which will provide a
     >      > pre-root-fs user-space. This new system should provide a simple
     >      > method for adding tasks to run during this early user-space,
     >      > and those who wish to use root-on-EVMS will just need to add
     >      > the EVMS tools to their initramfs. For 2.4 users, this means
     >      > using an initial ramdisk (initrd) to provide this same pre-root
     >      > user-space. Initrd setup is certainly awkward and often
     >      > distribution- specific. But we will do our best to provide
     >      > adequate instructions and assistance to those who need help in
     >      > that situation.
     >      >
     >      > Looking ahead, we *will* continue to *fully* support the 1.2.0
     >      > version of EVMS on 2.4 kernels, and possibly release a 1.2.1
     >      > version with some recent bug fixes. We will also make a
     >      > reasonable effort to maintain the current EVMS kernel driver on
     >      > 2.5. It will not go through any other major changes, but we
     >      > will try to keep it up-to-date and working with the latest 2.5
     >      > releases, until the new EVMS tools are complete. At that point,
     >      > the 2.5 EVMS driver will be dropped. Also, the new enhancements
     >      > we have been working on recently, such as clustering and volume
     >      > move, will only be developed under the new Engine model, and
     >      > will not be available for the current 1.2.x code base.
     >      >
     >      > So how long will this take? Currently, we are estimating that
     >      > we can have the user-space volume activation framework working,
     >      > along with initial support for most of the plugins, by early
     >      > 2003. Certain features, such as BBR and Snapshotting, may take
     >      > longer to work out the details of their operation. We will soon
     >      > open a new CVS tree to hold the new Engine code, leaving the
     >      > old trees as a repository for bug fixes to the 1.2.x version.
     >      >
     >      > In summary, we feel that this decision is the best way to
     >      > support our users for the long term. We want to provide EVMS on
     >      > current and future kernels, and we feel this change provides
     >      > the best method for achieving that. At the same time, this
     >      > addresses all of the concerns voiced by the kernel community. 
     >      > If anyone has any questions or concerns about this decision,
     >      > please email us or the EVMS mailing list at
     >      > evms-devel@lists.sf.net. We will be happy to answer any
     >      > questions or discuss these changes in more detail.
     >      >
     >      > Thank you,
     >      >
     >      > The EVMS Team
     >      > http://evms.sourceforge.net/
     >      > evms-devel@lists.sourceforge.net
     >      >
     >      >
     >      > -------------------------------------------------------
     >      > 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-announce mailing list
     >      > Evms-announce@lists.sourceforge.net
     >      > To subscribe/unsubscribe, please visit:
     >      > https://lists.sourceforge.net/lists/listinfo/evms-announce

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

Re: [Evms-announce] EVMS announcement

[Alan Cox]

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

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

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