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
> 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-announce mailing list
> Evms-announce@lists.sourceforge.net
> 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 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/