EVMS announcement

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]

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.

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

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.

[...]

It's not denial.  I'm just selective about the reality I accept.
	-- Bill Watterson

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

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>

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)

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

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

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,

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.

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.

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

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

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.

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>

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

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

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

Hendrik

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.

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.

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.

Thanks. I'll keep that in mind. :)

-Kevin

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

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

Especially because the code is so ugly :-)

That's a helper that's been on my todo for a long time, so it should be pending very shortly..

Jens Axboe

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.

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/

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.

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/

Followup to:  <[email protected]>
By author:    Alan Cox <[email protected]>
In newsgroup: linux.dev.kernel

I presume that means device mapper is capable of using checksum offloading and controller-based block duplication? If so, that's pretty damned nice. Good work :)

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

ataraid is just driving dumb ide controllers in the way bios raid does

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

I guess I meant it as a more general question than those specific devices.

-hpa

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

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

Our current software MD driver doesn't support doing that in hardware. It has the neccessary infrastructure to consider using hardware xor engines but I doubt its every actually more efficient to do so on low end devices.

Probably not. The only case where I can imagine it helps is when you get to push less data across the bus.

-hpa