[prev in list] [next in list] [prev in thread] [next in thread] 

List:       evms-devel
Subject:    [Evms-devel] Re: IBMs LVM?
From:       Kevin Corry <corryk () us ! ibm ! com>
Date:       2001-09-13 8:39:01
[Download RAW message or body]

Andreas, Christoph,

(Sorry this response is a couple days late. I don't subscribe to lkml, just
browse the archives once a week or so.)

> > You need code to do this for each different metadata format or
> > partition type. Luckily (hopefully?) most people won't have systems
> > with more than a couple different metadata formats at a time.
> > HOWEVER, you NEED to be able to migrate from one format to another,
> > so you will have periods when you have extra modules loaded during
> > a migration. 
>
> No - there is no reason we need support for migration in our volume 
> managment system. The reason to have a framework is excatly that we 
> can have multiple different formats. If there is a tool to provide 
> migration it's nice, but it shouldn't complicate the actual volume 
> managment core.

I think this particular issue is being slightly mistaken. There are no
facilities in EVMS to "migrate" one type of volume to another type of volume.
For instance, if a user has an OS/2 box and uses OS/2 LVM volumes, EVMS will
support that format directly. However, it currently does not allow that volume
to be converted to, say, a Linux LVM volume. If this is the user's desire, he
will have to create new volumes using the Linux LVM module, and move the data
between the volumes. In future designs there may be support for doing this kind
of operation on-line, but that would be as close as we would get to doing a
"migration".


> > > IF you don't have enough read the archives of the mailinglist
> > > about god-mode that allows even root to do anything and we come
> > > back. 
> >
> > It is not clear if you are you for or against "god-mode"? Would you 
> > like it so that it is easy to shoot themselves in the head (or it 
> > is so complex/manual that it is hard not to), or rather everyone in 
> > straight-jackets in rubber rooms (ala Windows)? Some safety is
> > needed, but there are also reasons to bypass that safety. I don't
> > know what the current state of "god-mode" is in the EVMS code (if
> > it is there, needed, whatever, so it is a moot point). 
>
> In unix we have the useruser (or more precise the capabilities model), 
> no need for a damn god mode. 

Well, I certainly find it interesting to hear you say this. This whole notion
(which I have personally thought is completely rediculous from the start) was
put in due to suggestions from you. We wanted to put basic safety checks into
the user-space code to prevent even root from doing things that would inherently
break the configuration of a running system. (i.e. Taking a disk out from within
a raid-1 configuration that has encryption on top of it and trying to use it for
another volume). Even the Linux LVM has these kind of basic checks (not allowing
a PV to be removed from a group if it has any part of an existing LV on top of
it). But you seemed to indicate that root should be able to anything he pleases.
Thus we decided on creating two modes in the user-space code, one for users who
want some basic protection from their own stupidity, and one for users who don't
mind shooting themselves in the foot. Personally, I would rather get rid of
"god-mode" and just require all of the basic sanity checks all the time. Dealing
with the errors that creep up in the other case is just too mind boggling.
Anyway, this is simply a user-space issue, and has nothing to do with the
kernel-side code.


> > > I DO think that EVMS will replace the current LVM code in the
> > > kernel. Why? - It already has 100% compatibility with the current
> > > LVM on-disk layout. 
> > 
> > With _which_ LVM on-disk layout (OOPS, this was a complaint to
> > Sistina :)) 
>
> Exactly. It was me and the EVMS LVM-emulation author that pointed out
> to the Sistina folks that there was NO need to have an incompatible
> change to the on-disk layout. In fact, the EVMS code can handle BOTH
> formats, and did so before LVM did. 

Just for the record, the LVM module in EVMS *should* correctly handle all of the
possible metadata situations that came up due to the LVM "upgrade" (as I
described on linux-lvm a couple weeks ago). And as Andreas said, we do have
support for partial VGs (missing a PV), and our release tomorrow will include
read-only support for partial LVs (one that spanned the missing PV) to support
limited data recovery.


> > > > - It removes knowlege of partitions out of the disk drivers and
> > > > makes them a simple form of LV. 
> > >
> > > No - it duplicates the partitions scanning code. It does not
> > > remove the simple partitioning code (which, BTW is not part of the
> > > drivers at all under Linux), makeing it's copy more complicated
> > > than the original version. 
> >
> > Well, there are obvious reasons for that. Some people won't want to
> > have EVMS in the kernel (clearly you are one of them), so their
> > patch can't just rip out the existing partition scanning code. Maybe
> > there will be a config option to not compile it later, or there will
> > be an "EVMS-lite" which handles basic partitions, or whatever. 
> >
> > In any case, I doubt an EVMS patch would be accepted if it removed
> > that code to start with. HOWEVER, since EVMS can handle ALL disk
> > devices, even just regular partitions, at some point it COULD be
> > possible to get rid of the mess of different major/minor numbers for
> > different disk types (hdX, sdX, cciss, rd, ida, etc) and assign all
> > of them to EVMS.
>
> I think such an patch would be accepted much more likely. You know
> Linus (and we all :)) likes ripping out code. 
>
> If you come and say: this patch nukes all special cases for MD, LVM
> and partition handling, the code is now X lines less I bet he will
> like it. 

We have discussed this quite a bit recently, and we seem pretty well split on
what we should do (as it seems you are). The crux of what we have decided is
that we don't want to suddenly force EVMS on all Linux users (by removing the
partition code, etc). Rather, we were going to put another option in the EVMS
configuration menu to allow removal of this code at compile time.

Personally I agree with Andreas. I'm of the impression that the more code we rip
up in the common kernel, the harder it will be to have our patch accepted. Right
now we just add a few lines to main.c and to the configuration files, and add
all of our code in a new directory in drivers. However, if Linus and others
truly want to get rid of "duplicate" code from the kernel before considering
EVMS, we can look into that. But I would rather hear some more opinions from
others on this list before we go down that path.


> > You complain about code bloat in EVMS, but having LVM, MD, 
> > VxVM, NT LDM, etc. all separate is also code bloat, 
> 
> I think al these are together smaller than EVMS. 
> At lest they don't have their own 200k linked list implementation :P 

On a very brief check, my LVM module in the EVMS kernel code is about 2800
lines, with the actual LVM kernel code taking up about 3700 lines.
All together, drivers/md has about 12k lines and drivers/evms has about 16k
lines. Of course, that also includes support for the partitioning code, generic
snapshotting, bad-block relocation, and OS/2 and AIX compatibility. However,
that doesn't currently include a port of MD. But I honestly can't see that being
more than another 2k lines.

As for the linked-list implementation, that is ONLY in the user-space code. I
suppose we could get rid of it there by rewriting the Engine in C++/STL, but I
don't think that would be enormously well-received either. :)


> With the problem that the IBM guys ignore me since someone told them
> that I'm "not part of the OpenSource movement". I started sending
> fixes in the very beginning.. 
> 
> > Maybe you can help them work on it? 
>
> If they stop ignoring me - sure. 

I don't believe we have ignored you at all. You sent us a bunch of very helpful
information earlier in the year, and nearly everything you suggested eventually
went into the code. Then we just stopped hearing from you. The last email I have
from you on the EVMS list is from mid-May. If you have more suggestions or
ideas, please let us know. If you have specific fixes or patches, send them in
and we will try to get them integrated. Andrew Clausen made numerous suggestions
about our overall design, and because of that we've made a very significant
internal change over the last month that will hopefully make the system more
robust and easy to understand and administer for the user. If you have similar
issues with the fundamental design, we will give your
ideas serious consideration.

Also, I don't believe anyone ever told us you were "not part of the OpenSource
movement". At least, no one has EVER said that to me. If they had I would have
laughed at them. The notion that you aren't a significant contributor to the
kernel should be rediculous to anyone who reads this list or browses the kernel
change-logs. :)


Anyway, I'm sorry if I sound like I'm ranting here. I just want to make sure the
record is finally set straight on some of these issues. If anyone has any
additional questions concerning EVMS, please cross-post them to
evms-devel@lists.sf.net. I will try to continue to monitor this list, but it is
very hard considering the amount of traffic.

Kevin Corry
corryk@us.ibm.com
Enterprise Volume Management System
http://www.sourceforge.net/projects/evms/

[prev in list] [next in list] [prev in thread] [next in thread]