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

This is one sad :( email to read, and Im sure it's
even more difficult to write. There can't be any winner
when public domain refuses a given work. I commend your=20
past and your continuing development effort.

Near term:
1. How long will EVMS1.2.0 & kernel2.4 be supported?

Looking further out:
1. Is EVMS runtime a throw away?
2. Is EVMS engine to modify for LVM2 support?
3. What will happen to the modular (plugins)?
     - AIX LVM
     - OS2 LVM
     - Device manager (local/san)
     - etc..

Thanks,
Michael.



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


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