RE2: [Evms-devel] EVMS announcement

Michael Nguyen (michael.nguyen@corosoft.com)
Tue, 5 Nov 2002 16:18:53 -0800


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
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:corryk@us.ibm.com]
> Sent: Tuesday, November 05, 2002 2:19 PM
> To: evms-devel@lists.sourceforge.net;
> evms-announce@lists.sourceforge.net
> Cc: linux-kernel@vger.kernel.org
> Subject: [Evms-devel] 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
> evms-devel@lists.sf.net. We will be happy to answer any
> questions or discuss these changes in more detail.
>
> Thank you,
>
> The EVMS Team
> http://evms.sourceforge.net/
> evms-devel@lists.sourceforge.net
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
Evms-devel mailing list
Evms-devel@lists.sourceforge.net
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/