login
Search
The EVMS team - seeing that the feature freeze has come and gone - has decided a drastical change in the direction of the project. Basically, they are going to rewrite the EVMS user-space tools to work with the multi-device drivers currently in the kernel (such as device mapper [story] and MD).
This will provide a lot of advantages over the current way. First, it lightens the developers' burden, because they'll have less kernel code to maintain. It will also simplify the EVMS tools and EVMS installation. And it will ultimately lead to a stabler, more mature EVMS.
Alan Cox [interview] commented:
"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."
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
From: Alan Cox
To: evms-devel, evms-announce, linux-kernel
Subject: Re: EVMS announcement
Date: 05 Nov 2002 23:37:50 +0000
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
From: James H. Cloos Jr.
To: evms-devel, evms-announce, linux-kernel
Subject: Re: EVMS announcement
Date: 05 Nov 2002 19:05:08 -0500
>>>>> "Kevin" == Kevin Corry writes:
> 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.
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
From: Kevin Corry
To: linux-kernel, evms-devel
Subject: Re: EVMS announcement
Date: Wed, 6 Nov 2002 09:21:16 -0600
On Tuesday 05 November 2002 18:05, James H. Cloos Jr. wrote:
> >>>>> "Kevin" == Kevin Corry writes:
> > In addition, this switch complicates having the root filesystem
> > 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
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.
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.
From: Alan Cox
To: evms-devel, linux-kernel
Subject: Re: [Evms-announce] EVMS announcement
Date: 06 Nov 2002 00:21:20 +0000
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)
From: Kevin Corry
To: evms-devel, linux-kernel
Subject: Re: [Evms-devel] EVMS announcement
Date: Tue, 5 Nov 2002 18:36:02 -0600
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
From: Mike Diehl
To: evms-devel, linux-kernel
Subject: Re: [Evms-devel] EVMS announcement
Date: Tue, 5 Nov 2002 20:45:58 -0500
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.
--
Mike Diehl
From: Alexander Viro
To: evms-devel, linux-kernel
Subject: Re: [Evms-devel] EVMS announcement
Date: Tue, 5 Nov 2002 23:48:25 -0500 (EST)
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...
From: Kevin Corry
To: evms-devel, linux-kernel
Subject: Re: [Evms-devel] EVMS announcement
Date: Wed, 6 Nov 2002 07:47:15 -0600
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.
Thanks. I'll keep that in mind. :)
-Kevin
mature
Nice to see how mature some people can be... even on lkml. :)