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
[email protected]. We will be happy to answer any questions or
discuss these changes in more detail.
Thank you,
The EVMS Team
http://evms.sourceforge.net/
[email protected]
On Tue, 2002-11-05 at 22:19, Kevin Corry wrote:
> 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
I plan to try and push LVM2 to Marcelo after the next release. Whether
he will take it I don't know. Obviously its good to have the ability to
move back nicely to older kernels.
> 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
Throwing away a big piece of code really sucks. I think however its the
right path - adding those things EVMS needs kernel side into a cleaner
framework and the tools is better than two systems in one kernel. I
appreciate you guys doing what looks to be the right thing for the Linux
project overall even when it must be a bitter disappointment.
Alan
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
> [email protected]. We will be happy to answer any questions or
> discuss these changes in more detail.
>
> Thank you,
>
> The EVMS Team
> http://evms.sourceforge.net/
> [email protected]
>
>
> -------------------------------------------------------
> 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
> [email protected]
> 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
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
> > [email protected]. We will be happy to answer any
> > questions or discuss these changes in more detail.
> >
> > Thank you,
> >
> > The EVMS Team
> > http://evms.sourceforge.net/
> > [email protected]
> >
> >
> > -------------------------------------------------------
> > 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
> > [email protected]
> > 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
Note the difference between LVM (the tools, the on-disk format, etc) and
device-mapper (simply a generic interface in the kernel). I suspect the
disasterous LVM experiences you've had were either with LVM1 (which did
not use device-mapper), or with some aspect of LVM2's userspace stuff
(which, I have yet to hear of any major problems with, other than
important features like pvmove not yet being implemented). There's no
reason why EVMS would need to emulate similar behavior.
On Tue, Nov 05, 2002 at 04:00:10PM -0500, 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.
>
>
>
>
> 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.
[...]
> > 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
> > [email protected]. We will be happy to answer any questions or
> > discuss these changes in more detail.
> >
> > Thank you,
> >
> > The EVMS Team
> > http://evms.sourceforge.net/
> > [email protected]
> >
> >
> > -------------------------------------------------------
> > 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
> > [email protected]
> > 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
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
It's not denial. I'm just selective about the reality I accept.
-- Bill Watterson
On Tue, 5 Nov 2002, 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.
> The biggest thing that EVMS had going for it was it's modular design.
So what's your point ? Device mapper will be an EVMS module, from
the user's point of view.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
On Tuesday 05 November 2002 06:40 pm, Andres Salomon wrote:
> Note the difference between LVM (the tools, the on-disk format, etc)
> and device-mapper (simply a generic interface in the kernel). I
> suspect the disasterous LVM experiences you've had were either with
> LVM1 (which did not use device-mapper), or with some aspect of LVM2's
> userspace stuff (which, I have yet to hear of any major problems with,
> other than important features like pvmove not yet being implemented).
> There's no reason why EVMS would need to emulate similar behavior.
I'm certainly willing to grant that things may have improved since the last
time I used LVM. I hope they have.
It's like the first time you taste sour milk. You just never forget the
taste it leaves in your mouth. LVM tastes the same to me, though it may be
completely stable/viable now. <rant off>
--
Mike Diehl
PGP Encrypted E-mail preferred.
Public Key via: http://dominion.dyndns.org/~mdiehl/mdiehl.asc
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)
> 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.
I think the decision not to include EVMS in 2.5 or 2.6 is a very poor one.
The EVMS group has been incredibly responsive and they have developed a very
robust and functional addition to Linux that was long overdue. I think that
*users* and functionality ought to be considered over design considerations
a little more often. If there can be two Intel EtherExpress Pro 100 drivers
(Becker and Intel versions) the precedent has already been set for inclusion
of kernel bits with similar functionality has it not?
A clean and reasonable design now has to be reworked and the results will be
reduced functionality and costs to the user. Costs in installation,
functionality, usability, and manageability. I hope a cutting edge project
like Linux isn't starting to fall prey to the idea that "It's always been
done that way."
I am seriously disappointed.
Eff Norwood
>>>>> "Kevin" == Kevin Corry <[email protected]> writes:
Kevin> However, the drawback to making this switch is losing
Kevin> automatic boot-time volume discovery. Activating EVMS volumes
Kevin> will now require a call to a user-space utility, which will
Kevin> need to be added to the system's init scripts in order to
Kevin> activate the volumes on each boot.
Kevin> In addition, this switch complicates having the root filesystem
Kevin> on an EVMS volume.
Actually, this isn't as much of an issue with 2.5-as-it-will-soon-be.
The initramfs stuff solves the problem for booting, and is exactly
where boot-time discovery should be.
You will need to ensure sufficient integration with hotplug to deal
properly with such things as external devices (usb, 1394, cardbus/
pcmcia, iscsi, docking stations, etc) and media bays. But this should
be relatively easy, yes?
Without initramfs, I find current evms' in-kernel discovery to be very
beneficial from the end-user standpoint, but early userpsace is clearly
the proper place for boot-time volume discovery just as it is for eg
nfsroot or similar (gfs root, root on iscsi or usb or 1394).
In short, your new plans are the way to go, but do be sure to take
advantage of all the kernel offers or will offer.
-JimC
On Tue, Nov 05, 2002 at 04:00:10PM -0500, Mike Diehl wrote:
> Well, I'm a bit disapointed. My experience with LVM has been nothing short
> of disasterous;
I think you'll find LVM2 much more pleasant than LVM1. It's a
reimplementation with a very different (minimalist :) architecture.
Cheers,
Andrew
Hi Mike,
On Tuesday 05 November 2002 15:11, 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.
I'm sorry you feel disappointed. But I assure you that EVMS will continue to
provide the same experience you have come to expect. All this decision really
means is that we will be building on a different kernel component, instead of
providing our own. All of the EVMS tools and libraries will essentially be
unchanged from the perspective of most users.
> 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.
And we will still maintain that modular design. In fact, we see this as
making the design even more modular, since it won't have to be tied to a
single kernel driver. Device mapper can be used for supporting disk
partitions, LVM, and some other plugins. The MD driver can be used to support
software RAID. We've even had thoughts about building on the existing loop
driver in order to provide the partition-level encryption that you mentioned.
And all of this from a single, unified interface.
> But never mind me. I'm just a linux user, not a linux developer.
Actually, it *is* the users that we are most concerned with. This is why we
are going to make such an effort to keep our tools as unchanged as possible.
But we really do think that this is the best solution in the long term, for
both the users and the developers.
If you continue to have any concerns about this, please let us know. We will
do our best to address them and explain any other details about this change
that you are unsure of.
-Kevin
On 2002-11-05T16:19:10,
Kevin Corry <[email protected]> said:
Kevin,
this must have been a very painful decision. I publically applaud you for
making it.
The great benefit from EVMS is the unified toolset for the administrator. It
is impressive that you are willing to rework this on top of a "Not Invented
Here" framework. I'm not sure whether my ego would have allowed the same
decision ;-)
The Device-Mapper seems to appeal more to the kernel community (and I'll agree
it is quite impressively neat code), and the EVMS management aspect appeals to
users. I hope that merging these will appeal to all. (It certainly does to
me).
I'm most certainly looking forward to seeing the clustering support comeing
;-)
Now, an interesting question is whether the md modules etc will simply be
continued to be used or whether they'll make use of the DM engine too? Can
they be made "plugins" to DM or the EVMS framework? Or even, could EVMS (in
theory) parse the meta-data from a legacy md device and just setup a DM
mapping for it? That would appeal to me quite a bit. I really need to start
reading up on it...
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
Principal Squirrel
SuSE Labs - Research & Development, SuSE Linux AG
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
-- Capt. Edward A. Murphy -- Louis Pasteur
On Tue, 5 Nov 2002, Eff Norwood wrote:
> A clean and reasonable design now has to be reworked and the results
> will be reduced functionality and costs to the user. Costs in
> installation, functionality, usability, and manageability.
So, you're volunteering to maintain the EVMS subsystem for 2.5 ?
If not, I propose you let Kevin and the other EVMS developers
make the decision.
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
> So, you're volunteering to maintain the EVMS subsystem for 2.5 ?
>
> If not, I propose you let Kevin and the other EVMS developers
> make the decision.
So, having EVMS not included in the kernel was the decision they wanted to
make?
If not, then I propose you be a little more reasonable and think about what
this decision does to all the work thus far put into EVMS.
Eff
On Tue, 5 Nov 2002, Eff Norwood wrote:
> So, having EVMS not included in the kernel was the decision they wanted
> to make?
Not having the kernel part of EVMS doesn't mean EVMS isn't
available to users. EVMS can get a lot of the functionality
using device mapper.
> If not, then I propose you be a little more reasonable and think about
> what this decision does to all the work thus far put into EVMS.
The work put into EVMS this far is maybe 20% of the work that
maintaining EVMS would cost once it's in the kernel.
Developing code is nowhere near as much work as maintaining it
indefinately. Using the device mapper framework makes a lot of
sense from many points of view.
regards,
Rik
--
Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/ http://distro.conectiva.com/
Current spamtrap: <a href=mailto:"[email protected]">[email protected]</a>
On Tue, 5 Nov 2002, Eff Norwood wrote:
> > So, you're volunteering to maintain the EVMS subsystem for 2.5 ?
> >
> > If not, I propose you let Kevin and the other EVMS developers
> > make the decision.
>
> So, having EVMS not included in the kernel was the decision they wanted to
> make?
>
> If not, then I propose you be a little more reasonable and think about what
> this decision does to all the work thus far put into EVMS.
This decision (to move the bulk of EVMS code to userland and isolate the
changes needed in the kernel) *definitely* means less work in the long
run - for EVMS people in the first place.
Userland code is easier to write. There one has full runtime environment
and that alone means a lot. There one has no 8Kb limit on the stack size.
There one has memory protection. And there code doesn't have to do anything
about the changes of kernel internals. It's also easier to debug - for very
obvious reasons.
The goal is to provide functionality, not to put it in the kernel - the
latter always means harder life. It is the last resort measure ("we have
no way to do that in userland with acceptable performance and correctness,
damn, time to deal with the kernel side") and finding a way to make do
with more compact kernel part (ideally - already maintained by somebody
else ;-) is always good news.
And I seriously doubt that work thus far put into EVMS goes down the drain
from move to userland - they would have to be absolutely incompetent for
that to be the case and I don't see what allows you to accuse them in that.
What that decision does mean is serious one-time effort that makes life
easier once it's done. And that had taken real courage - my applause to
them (and not only mine, while we are at). What they had done was pretty
amazing and my respect to the team that had chosen to do the right thing,
had been able to defend that decision and to their management that had allowed
that has just gone _way_ up. Bravo, folks. And best luck - seriously.
I respect very few people. These I _do_ respect. A lot.
On Tuesday 05 November 2002 07:36 pm, Kevin Corry wrote:
> Hi Mike,
I don't know if you remember me, but you bailed me out from some trouble I
had with LVM.... TWICE!
> I'm sorry you feel disappointed. But I assure you that EVMS will
> continue to provide the same experience you have come to expect. All
> this decision really means is that we will be building on a different
> kernel component, instead of providing our own. All of the EVMS tools
> and libraries will essentially be unchanged from the perspective of
> most users.
I've had some time to think about this. As a programmer, I am lothe to
re-invent any wheel that someone else already has. I think this may be how
you guys came to this decision.
> And we will still maintain that modular design. In fact, we see this
> as making the design even more modular, since it won't have to be tied
> to a single kernel driver. Device mapper can be used for supporting
> disk partitions, LVM, and some other plugins. The MD driver can be
> used to support software RAID. We've even had thoughts about building
> on the existing loop driver in order to provide the partition-level
> encryption that you mentioned. And all of this from a single, unified
> interface.
It's beginning to sound like you may be able to leverage the work that went
into MD and LVM and consentrate on (perhapse) some really cool stuff, like
partition-level encyption, or the disk partitioning scheme involving RAID,
NBD's and LVM that Alan Cox outlined in another post.
> > But never mind me. I'm just a linux user, not a linux developer.
>
> Actually, it *is* the users that we are most concerned with. This is
> why we are going to make such an effort to keep our tools as unchanged
> as possible. But we really do think that this is the best solution in
> the long term, for both the users and the developers.
As I said in a different post, that was a cheep shot on my part. I'm usually
much bigger than that.
So, let me try to understand. The EVMS team is going to rip out the guts of
their user-land utils in order to comply with the existing (mainstream) API,
and abandon their own API. This should reduce the amount of code actually in
the kernel. (ignoring the user-land v. kernel-level discovery debate)
Na, I can't ignore the debate. I can't wait to see how user-land descovery
will be implemented. There is something intrinsically "nice" about having an
OS automatically discover every aspect of a machine I'm installing on. I
guess it's going to fall to the Linux distributors to package this system
well. If they don't, first-time Mandrake or RH installers will be doomed to
that (shudder) other operating system.
> If you continue to have any concerns about this, please let us know.
> We will do our best to address them and explain any other details
> about this change that you are unsure of.
I'll just have to wait. BTW, Kevin, if you are ever in Albuquerque, NM. let
me know; I still owe you a beer. <grin>
--
Mike Diehl
PGP Encrypted E-mail preferred.
Public Key via: http://dominion.dyndns.org/~mdiehl/mdiehl.asc
On Tue, 5 Nov 2002, Mike Diehl wrote:
> Na, I can't ignore the debate. I can't wait to see how user-land descovery
> will be implemented. There is something intrinsically "nice" about having an
> OS automatically discover every aspect of a machine I'm installing on. I
Kernel _can't_ do that. In principle. Simply because part of the kernel
that would know how to talk with that PCI card (which just happens to be
a SCSI adapter) happens to be a module that lives on a filesystem that
lives on a different server and will be accessible only after we configure
this NIC. There is no way in hell to tell what devices sit on the SCSI
bus behind that card. Not without userland participation in the process.
So like it or not, userland is involved. The best thing that can be done
is exposing the list of block devices (with information about them) that
kernel knows of + passing events (device added/removed/etc.) to userland.
We have both - one in sysfs and another as calls of /sbin/hotplug. What's
more, we are about to get them very early, so a lot of warts become not
necessary (all drivers' setup happens with early userland already in place,
so we the things that had to be done manually can use generic mechanisms).
Note that both interfaces are still changing and figuring out what is
really needed will certainly be easier with non-trivial users of these
mechanisms. EVMS definitely will be one of such users...
On Tuesday 05 November 2002 11:48 pm, Alexander Viro wrote:
> On Tue, 5 Nov 2002, Mike Diehl wrote:
> > Na, I can't ignore the debate. I can't wait to see how user-land
> > descovery will be implemented. There is something intrinsically
> > "nice" about having an OS automatically discover every aspect of a
> > machine I'm installing on. I
>
> Kernel _can't_ do that. In principle. Simply because part of the
> kernel that would know how to talk with that PCI card (which just
> happens to be a SCSI adapter) happens to be a module that lives on a
> filesystem that lives on a different server and will be accessible
> only after we configure this NIC. There is no way in hell to tell
> what devices sit on the SCSI bus behind that card. Not without
> userland participation in the process.
I don't know about you, but my NIC, fs, and Disk drivers are compiled into my
kernel. But what you describe is also pretty cool. I could have a central
server and the rest of my machines would simply become part of a cluster and
use the same drives, for the most part. Neat.
--
Mike Diehl
PGP Encrypted E-mail preferred.
Public Key via: http://dominion.dyndns.org/~mdiehl/mdiehl.asc
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
> [email protected]
> To subscribe/unsubscribe, please visit:
> https://lists.sourceforge.net/lists/listinfo/evms-devel
On Tuesday 05 November 2002 19:45, Mike Diehl wrote:
>
> I don't know if you remember me, but you bailed me out from some trouble I
> had with LVM.... TWICE!
I do in fact remember you. :) If I scrounge around on my computer at work, I
could probably still find all the information you sent me about the problems
you were having.
> So, let me try to understand. The EVMS team is going to rip out the guts
> of their user-land utils in order to comply with the existing (mainstream)
> API, and abandon their own API. This should reduce the amount of code
> actually in the kernel. (ignoring the user-land v. kernel-level discovery
> debate)
To say we are going to rip out the guts of the user-land tools is probably a
bit extreme. The user tools already do their own version of volume discovery,
separate from the kernel. So since that logic already exists, we simply need
to add some processing after that discovery to communicate with the kernel
drivers to activate the volumes. And yes, this dramatically reducing the
amount of kernel code needed. In our current kernel driver, I'd say easily 50
to 75% of the code was just for the in-kernel volume discovery.
> Na, I can't ignore the debate. I can't wait to see how user-land descovery
> will be implemented. There is something intrinsically "nice" about having
> an OS automatically discover every aspect of a machine I'm installing on.
> I guess it's going to fall to the Linux distributors to package this system
> well. If they don't, first-time Mandrake or RH installers will be doomed
> to that (shudder) other operating system.
Yes, in order for something like volume management to be easy and seemless to
user, it should be presented to them at the time they install their system.
Having to go back and setup up volumes after the OS is installed is
definitely cumbersome. We are hoping this change will make it easier for EVMS
to work on a wider variety of distributions. But we are already on our way.
We've done a lot of work with UL, Debian, and Gentoo, and this will hopefully
make things easier for those folks in the long run.
> I'll just have to wait. BTW, Kevin, if you are ever in Albuquerque, NM.
> let me know; I still owe you a beer. <grin>
Thanks. I'll keep that in mind. :)
-Kevin
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
On Wed, 2002-11-06 at 00:16, Lars Marowsky-Bree wrote:
> Now, an interesting question is whether the md modules etc will simply be
> continued to be used or whether they'll make use of the DM engine too? Can
> they be made "plugins" to DM or the EVMS framework? Or even, could EVMS (in
> theory) parse the meta-data from a legacy md device and just setup a DM
> mapping for it? That would appeal to me quite a bit. I really need to start
> reading up on it...
I'm certainly hoping to kill off ataraid/pdcraid/hptraid by using device
mapper and md
On Wed, 2002-11-06 at 14:55, Alan Cox wrote:
> On Wed, 2002-11-06 at 00:16, Lars Marowsky-Bree wrote:
> > Now, an interesting question is whether the md modules etc will simply be
> > continued to be used or whether they'll make use of the DM engine too? Can
> > they be made "plugins" to DM or the EVMS framework? Or even, could EVMS (in
> > theory) parse the meta-data from a legacy md device and just setup a DM
> > mapping for it? That would appeal to me quite a bit. I really need to start
> > reading up on it...
>
> I'm certainly hoping to kill off ataraid/pdcraid/hptraid by using device
> mapper and md
absolutely. The biggest issue with this is that DM needs to be able to
handle chunks where 1 page is split across 2 strides on disk... if/once
DM (and BIO) can deal with that the rest isn't hard...
On Wed, Nov 06 2002, Arjan van de Ven wrote:
> On Wed, 2002-11-06 at 14:55, Alan Cox wrote:
> > On Wed, 2002-11-06 at 00:16, Lars Marowsky-Bree wrote:
> > > Now, an interesting question is whether the md modules etc will simply be
> > > continued to be used or whether they'll make use of the DM engine too? Can
> > > they be made "plugins" to DM or the EVMS framework? Or even, could EVMS (in
> > > theory) parse the meta-data from a legacy md device and just setup a DM
> > > mapping for it? That would appeal to me quite a bit. I really need to start
> > > reading up on it...
> >
> > I'm certainly hoping to kill off ataraid/pdcraid/hptraid by using device
> > mapper and md
>
> absolutely. The biggest issue with this is that DM needs to be able to
Especially because the code is so ugly :-)
> handle chunks where 1 page is split across 2 strides on disk... if/once
> DM (and BIO) can deal with that the rest isn't hard...
That's a helper that's been on my todo for a long time, so it should be
pending very shortly..
--
Jens Axboe
On Tuesday 05 November 2002 18:16, Lars Marowsky-Bree wrote:
> Now, an interesting question is whether the md modules etc will simply be
> continued to be used or whether they'll make use of the DM engine too? Can
> they be made "plugins" to DM or the EVMS framework?
I think the MD kernel modules certainly *could* be ported to the dev-mapper
framework. But right now, from EVMS's standpoint, there is no need to force
that change just yet. If it is determined in the future that that would be a
better direction to go, for us it would just mean re-coding the user-space MD
plugin to talk to dev-mapper instead of the MD driver. But a lot of work has
gone into the MD driver during 2.5, so I would personally think such a change
won't happen until at least 2.7.
> Or even, could EVMS (in
> theory) parse the meta-data from a legacy md device and just setup a DM
> mapping for it? That would appeal to me quite a bit. I really need to start
> reading up on it...
The pretty much exactly what does/will happen, except EVMS will talk to the
MD driver now (maybe DM in the future).
--
Kevin Corry
[email protected]
http://evms.sourceforge.net/
On Tuesday 05 November 2002 18:05, James H. Cloos Jr. wrote:
> >>>>> "Kevin" == Kevin Corry <[email protected]> writes:
> Kevin> In addition, this switch complicates having the root filesystem
> Kevin> on an EVMS volume.
>
> Actually, this isn't as much of an issue with 2.5-as-it-will-soon-be.
> The initramfs stuff solves the problem for booting, and is exactly
> where boot-time discovery should be.
Yep. This is what I was briefly trying to explain in the announcement. With
initramfs stuff finally going into 2.5, root-on-complex-volume should become
far less of an issue. For our users on 2.4, we will have to help them wade
through initrd for the time being. My real hope is that initramfs will
provide a much simpler method (compared to initrd) for adding new tools,
scripts, etc to be run during early userspace. The info I've gathered about
it so far seems to indicate this will be the case.
> You will need to ensure sufficient integration with hotplug to deal
> properly with such things as external devices (usb, 1394, cardbus/
> pcmcia, iscsi, docking stations, etc) and media bays. But this should
> be relatively easy, yes?
Hopefully, yes. We will obviously want to take full advantage of hotplug, and
any other device-level services that are available.
--
Kevin Corry
[email protected]
http://evms.sourceforge.net/
On Wed, 06 Nov 2002, Andrew Clausen wrote:
> On Tue, Nov 05, 2002 at 04:00:10PM -0500, Mike Diehl wrote:
> > Well, I'm a bit disapointed. My experience with LVM has been nothing short
> > of disasterous;
>
> I think you'll find LVM2 much more pleasant than LVM1. It's a
> reimplementation with a very different (minimalist :) architecture.
What's the current LVM2 status? I've got EVMS up and running in a couple
of minutes, but finding LVM2 stuff, let alone documentation, gives me a
hard time. And yes I know it's the testing stuff at sistina.com, so I
hope I'm looking at the right web site...
--
Matthias Andree
On Wed, Nov 06, 2002 at 10:33:29PM +0100, Matthias Andree wrote:
> On Wed, 06 Nov 2002, Andrew Clausen wrote:
>
> > On Tue, Nov 05, 2002 at 04:00:10PM -0500, Mike Diehl wrote:
> > > Well, I'm a bit disapointed. My experience with LVM has been nothing short
> > > of disasterous;
> >
> > I think you'll find LVM2 much more pleasant than LVM1. It's a
> > reimplementation with a very different (minimalist :) architecture.
>
> What's the current LVM2 status? I've got EVMS up and running in a couple
> of minutes, but finding LVM2 stuff, let alone documentation, gives me a
> hard time. And yes I know it's the testing stuff at sistina.com, so I
> hope I'm looking at the right web site...
Sistina has a new website, it took me quite a few clicks to find where
they'd hidden stuff:
http://www.sistina.com/products_lvm_download.htm
or
ftp://ftp.sistina.com/pub/LVM2/
I consider LVM2 to be more bug free than LVM1, the only thing holding
people back is the fact that they will have to patch the kernel to get
dm. Then upgrading from LVM1 is simply a question of building
libdevmapper and the LVM2 tools and using them. There will be a new
release next week that will a bit more documentation.
- Joe
On Tue, Nov 05, 2002 at 04:19:10PM -0600, 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.
Hi Kevin,
I think that's a very good move for EVMS in the long term. You will
be able to provide the users what they want (an easy to user and
integrated volume managment solution) without having the pain of
maintaining a large base of kernel-level code.
Of course there will be some hassle for you now, like adding DM plugins
for higher raid levels, etc.. But in the end I guess it will hope both
EVMS and Linux. EVMS by reducing the scope of the project without
reducing it's functionality, the Linux by having a modular and leight-weight
in kernel volume-managment solution with many eyes looking at it, using
it and improving it. I guess you will find a bunch of suboptimal things
in DM very soon and I hope you will help the kernel community in fixing
it. This of course means also that DM will hopefully get an integral part
of the kernel, not an Sistina Project like LVM1.
I (and I guess many other kernel developers interested in storage
handling) will look forward to the comments who the current kernel-level
storage managment facilities are useable by an unified userland engine
handling it, and I guess mthere will be many obvious improvement.
I'm also looking forward to IBM's opensource cluster volumemanagment
integration as competitions to Sistina's propritary addons.
I wish you all luck with your new direction and expect me and other kernel
developers in that area to help you wherever we can.
Christoph