IBMs LVM ?

IBMs LVM ?

[David Balazic]

Hi!

I heard rumors about IBM porting their LVM code from AIX to Linux.
I guess the current LVM code is not from IBM ?
Will it be replaced with the one from IBM ?
Comments ?

-- 
David Balazic
--------------
"Be excellent to each other." - Bill S. Preston, Esq., & "Ted" Theodore Logan
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Re: IBMs LVM ?

[Christoph Hellwig]

In article <3B9E255C.8943D6BB@uni-mb.si> you wrote:
> Hi!

> I heard rumors about IBM porting their LVM code from AIX to Linux.

IBM has an OpenSource volume manager called evms, and although
it does support AIX Volumes is has it's root in IBM's OS/2
volume management system.  (I believe someone at IBM thinks of PCs
when hearing Linux so all their ports start from OS/2...)

> I guess the current LVM code is not from IBM ?

The current code is from Heinz Maulshagen and now matained by Sistina,
the company he works for.

> Will it be replaced with the one from IBM ?

ALthough the current LVM has its's issues I hope not so - the current
EVMS is the best example on hhow to not write kernel subsystems.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.

Re: IBMs LVM ?

[Andreas Dilger]

On Sep 11, 2001  17:26 +0200, Christoph Hellwig wrote:
> > I heard rumors about IBM porting their LVM code from AIX to Linux.
> 
> IBM has an OpenSource volume manager called evms, and although
> it does support AIX Volumes is has it's root in IBM's OS/2
> volume management system.  (I believe someone at IBM thinks of PCs
> when hearing Linux so all their ports start from OS/2...)

Actually, this isn't quite correct.  Yes, the EVMS folks started with
the LVM design from OS/2 (which was based on AIX LVM, but not compatible).
However, IBM DID GPL the AIX 4.3 LVM code, and there IS support for AIX
VGs under EVMS.

> > Will it be replaced with the one from IBM ?
> 
> ALthough the current LVM has its's issues I hope not so - the current
> EVMS is the best example on hhow to not write kernel subsystems.

Do you have a specific complaint?  The current LVM kernel code isn't all
that robust either (and the user-space code is not very pretty).

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.
- It already has 100% compatibility with AIX LVM code.
- It is already possible to do LVM autoconfig of volumes within the kernel
  without needing an initrd to activate the volumes.
- It removes knowlege of partitions out of the disk drivers and makes them
  a simple form of LV.
- It is already possible to use partial Linux-LVM volumes (i.e. use LVs
  that are 100% available in a VG, even if a disk is bad/missing).  You
  can't do that with the current LVM (sometimes you can't even do it if
  ALL of the disks are there).
- The AIX LVM on-disk metadata layout is FAR more robust than the current
  LVM metadata layout.  While this is supposed to be fixed for Linux-LVM
  at some point, the previous Linux-LVM changes have been TERRIBLE with
  respect to compatibility, while EVMS is DESIGNED to support multiple
  on-disk metadata layouts.
- It is possible (not done yet) to add things like NT Logical Disk Manager
  (NT LVM-stuff) into EVMS.
- It is possible (not done yet) to add HPUX LVM/veritas/OSF volume stuff.
- It is possible to merge MD RAID support into EVMS also, to support all
  of the different RAID layouts with common code*.

All in all, instead of having things like striping/RAID-1/concatenation/
RAID-5 reimplemented in each subsystem (e.g. LDM/MD/veritas/etc) we can
take the current MD code and make it a layer in EVMS which can handle all
of these cases.

(*) While the exact on-disk layout of each RAID implementation may vary
slightly (block sizes, stripe widths, etc), I'm guessing that the majority
of it is common enough that we can re-use the existing MD code (parity
calculation, resync, etc) to handle most kinds of RAID-0/1/5 setups.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: IBMs LVM ?

[Christoph Hellwig]

On Tue, Sep 11, 2001 at 11:57:13AM -0600, Andreas Dilger wrote:
> On Sep 11, 2001  17:26 +0200, Christoph Hellwig wrote:
> > > I heard rumors about IBM porting their LVM code from AIX to Linux.
> > 
> > IBM has an OpenSource volume manager called evms, and although
> > it does support AIX Volumes is has it's root in IBM's OS/2

		^^^^^^^^^^^^^^^^^^

> > volume management system.  (I believe someone at IBM thinks of PCs
> > when hearing Linux so all their ports start from OS/2...)
> 
> Actually, this isn't quite correct.  Yes, the EVMS folks started with
> the LVM design from OS/2 (which was based on AIX LVM, but not compatible).
> However, IBM DID GPL the AIX 4.3 LVM code, and there IS support for AIX
> VGs under EVMS.

Where is the AIX LVM code?

> > > Will it be replaced with the one from IBM ?
> > 
> > ALthough the current LVM has its's issues I hope not so - the current
> > EVMS is the best example on hhow to not write kernel subsystems.
> 
> Do you have a specific complaint?  The current LVM kernel code isn't all
> that robust either (and the user-space code is not very pretty).

Please take a barf-bag, look at the code, look at the unneded abstrations,
look at the uneeded interfaces, look at the code-duplication, look
at the over-engineering.

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.

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

> - It already has 100% compatibility with AIX LVM code.

The code is there, yes.

> - It is already possible to do LVM autoconfig of volumes within the kernel
>   without needing an initrd to activate the volumes.

I had that for LVM 0.8 as well, that's a year ago now.

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

> - It is already possible to use partial Linux-LVM volumes (i.e. use LVs
>   that are 100% available in a VG, even if a disk is bad/missing).  You
>   can't do that with the current LVM (sometimes you can't even do it if
>   ALL of the disks are there).

Yupp, nice thing.

> - The AIX LVM on-disk metadata layout is FAR more robust than the current
>   LVM metadata layout.  While this is supposed to be fixed for Linux-LVM
>   at some point, the previous Linux-LVM changes have been TERRIBLE with
>   respect to compatibility, while EVMS is DESIGNED to support multiple
>   on-disk metadata layouts.

Yes, because it is a Meta-LVM, not an actualy inplementation.
I _really_ want something like that in 2.5 - but not this horrible IBM
implementation.

> - It is possible (not done yet) to add things like NT Logical Disk Manager
>   (NT LVM-stuff) into EVMS.
> - It is possible (not done yet) to add HPUX LVM/veritas/OSF volume stuff.

That's the same argument as above.

> - It is possible to merge MD RAID support into EVMS also, to support all
>   of the different RAID layouts with common code*.
> 
> All in all, instead of having things like striping/RAID-1/concatenation/
> RAID-5 reimplemented in each subsystem (e.g. LDM/MD/veritas/etc) we can
> take the current MD code and make it a layer in EVMS which can handle all
> of these cases.
> 
> (*) While the exact on-disk layout of each RAID implementation may vary
> slightly (block sizes, stripe widths, etc), I'm guessing that the majority
> of it is common enough that we can re-use the existing MD code (parity
> calculation, resync, etc) to handle most kinds of RAID-0/1/5 setups.

Nope - I'm currently working on implementing VxVM support, and I have
to redo all the RAID stuff because it is so incomaptible.

If you have a design to share the RAID engine for very different layouts:
nice - but I don'T see the relation to EVMS.

	Christoph

-- 
Whip me.  Beat me.  Make me maintain AIX.

Re: IBMs LVM ?

[Andreas Dilger]

On Sep 11, 2001  20:06 +0200, Christoph Hellwig wrote:
> On Tue, Sep 11, 2001 at 11:57:13AM -0600, Andreas Dilger wrote:
> > Do you have a specific complaint?  The current LVM kernel code isn't all
> > that robust either (and the user-space code is not very pretty).
> 
> Please take a barf-bag, look at the code, look at the unneded abstrations,
> look at the uneeded interfaces, look at the code-duplication, look
> at the over-engineering.

Well, you don't get anything for free.  You need to have some abstraction
in order to handle multiple LVM-type systems in a useful way, I don't see
any way around that.  As for the kernel code, I don't see TOO much
abstraction.

- You need code to read each separate on-disk format (partition headers,
  LVM metadata, etc)
- You need code to combine each of these into some useful "volume"
- You need code to do mapping from input volume/block to output disk/block
- You need code to be able to modify a volume metadata.

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.

Consider EVMS to be the VFS for block devices.  The VFS abstracts a lot
of common code out of the filesystems so that each individual one can be
less complex.  Yes, there is still duplication within the filesystems,
but it would be much moreso if the VFS didn't exist.  There is a lot of
abstraction in the VFS, but it is NOT bloat, it is code consolidation.
As enough filesystems need a specific feature, it is abstracted out of
the multiple filesystems and put into the VFS for all to use.

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

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

> > - It is already possible to do LVM autoconfig of volumes within the kernel
> >   without needing an initrd to activate the volumes.
> 
> I had that for LVM 0.8 as well, that's a year ago now.

But, strangely it didn't make it into the LVM codebase.  Why is that?
I'm not blaming you, of course.  EVMS is at least a SourceForge project.

> > - 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.  Since EVMS
only needs a minor number for the end-result volume (which may represent
many individual disks, and doesn't need a minor for unused partitions),
we would likely not have any shortage of block major numbers.  Consider
10*hdX*256 + 8*sdX*256 + MD*256 + 8*CCISS*256 + 8*DAC960*256 + 8*IDA*256...
and it is a long time until you have 10k+ VISIBLE volumes on a single system.

> > - The AIX LVM on-disk metadata layout is FAR more robust than the current
> >   LVM metadata layout.  While this is supposed to be fixed for Linux-LVM
> >   at some point, the previous Linux-LVM changes have been TERRIBLE with
> >   respect to compatibility, while EVMS is DESIGNED to support multiple
> >   on-disk metadata layouts.
> 
> Yes, because it is a Meta-LVM, not an actualy inplementation.
> I _really_ want something like that in 2.5 - but not this horrible IBM
> implementation.

Maybe you can help them work on it?  They have recently just redone a lot
of the code, partly based on input from Andrew Clausen.  I don't see any
other similar projects out there, and I think it is a waste of effort to
complain about work that is done rather than fix it.  I tried for a long
time (while it was still my job to do so) to fix the current Linux-LVM
code, and I only had very minimal impact.  Even so, Linux-LVM will never
become a Meta-LVM without AT LEAST as much "mess" as EVMS, and probably
will contain a lot more.

IBM is at least doing something about this by putting their code where
their mouth is.  Nothing is ever perfect.  Consider MD RAID - it isn't
even compatible between "stock" 2.2 and 2.2+Mingo-0.9RAID patches (which
is one reason why Alan never accepted the 0.9 MD RAID into 2.2, despite the
fact that ALL distros used the 0.9 MD RAID patches).  With a framework like
EVMS it is possible to have both of the on-disk formats supported, and
migrate from one to the next (maybe even while the system is in use), and
then unload the module that supports the old format.

> > (*) While the exact on-disk layout of each RAID implementation may vary
> > slightly (block sizes, stripe widths, etc), I'm guessing that the majority
> > of it is common enough that we can re-use the existing MD code (parity
> > calculation, resync, etc) to handle most kinds of RAID-0/1/5 setups.
> 
> Nope - I'm currently working on implementing VxVM support, and I have
> to redo all the RAID stuff because it is so incomaptible.

The question is - will the VxVM support be yet ANOTHER separate code base
in the kernel?  You complain about code bloat in EVMS, but having LVM, MD,
VxVM, NT LDM, etc. all separate is also code bloat, and each one needs
separate admin tools.  Remember - EVMS is also modular, so you only need
the support for "LVM" types that you use.  The real benefit, however, is
that since it is integrated, you _could_ cleanly migrate from Linux-LVM
and/or MD-RAID and/or NT-LDM to whatever you wanted (maybe even on a live
system) if EVMS is handling all of the kernel interfaces for them.  I don't
think you could ever do that without full backup/restore on separate tools.

> If you have a design to share the RAID engine for very different layouts:
> nice - but I don'T see the relation to EVMS.

No, I can't say I do - it was purely speculation based on the concept that
RAID-1 and RAID-5 are GENERALLY the same concept.  Maybe the reason VxVM
is so different is that it also incorporates "LVM" style function as well?
Note that NT-LDM ALSO has RAID-0/1/5 modes (not yet supported by the LDM
driver) which will eventually need support.  Do you want the number of RAID
implementations in the kernel to grow without bound, or rather try and
consolidate them (where possible) into a generic interface like EVMS?

Again, if EVMS is the VFS of block devices, then we can consolidate RAID
code into a single place.  Yes, there may be RAID layouts that are too
different from the common code, but hopefully we will avoid duplication
for EACH new layout that we need to support.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: IBMs LVM ?

[Christoph Hellwig]

On Tue, Sep 11, 2001 at 01:15:31PM -0600, Andreas Dilger wrote:
> Well, you don't get anything for free.  You need to have some abstraction
> in order to handle multiple LVM-type systems in a useful way, I don't see
> any way around that.  As for the kernel code, I don't see TOO much
> abstraction.
> 
> - You need code to read each separate on-disk format (partition headers,
>   LVM metadata, etc)
> - You need code to combine each of these into some useful "volume"
> - You need code to do mapping from input volume/block to output disk/block
> - You need code to be able to modify a volume metadata.

Yupp.


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

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

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

Of course they don't, but Sistina doesn't like staying with one version
more than a few month.  See my compat code to support 0.8 volumes on 0.9
that got rejected.

> But, strangely it didn't make it into the LVM codebase.  Why is that?

Why didn't all your nice stuff get merged? :P

> I'm not blaming you, of course.  EVMS is at least a SourceForge project.

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

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

The naming doesn't matter.  (BTW, EVMS is a damn stupid name..).
Either we do the - as you say - VFS for blockdevices or we don't - it doesn't
make sense to do it conditional.  Wether the complicated drivers are actually
use, and wether people want to use the integrated userspace soloutions is
a very different question.

> 
> In any case, I doubt an EVMS patch would be accepted if it removed that
> code to start with.

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.

> HOWEVER, since EVMS can handle ALL disk devices,

A few days I read that thread on the EVMS list about only detecting
SCSI and IDE drives yet - I probably got that wrong?..

> 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.  Since EVMS
> only needs a minor number for the end-result volume (which may represent
> many individual disks, and doesn't need a minor for unused partitions),
> we would likely not have any shortage of block major numbers.  Consider
> 10*hdX*256 + 8*sdX*256 + MD*256 + 8*CCISS*256 + 8*DAC960*256 + 8*IDA*256...
> and it is a long time until you have 10k+ VISIBLE volumes on a single system.

Yes, that's a nice thing and in fact linux already posted his opinion
about all disk drivers sharing the major numbers (for 2.5?).

But that just needs a small assignement layer (like sound_core), not
something as complex as EVMS.  Or a bugfree devfs.

> 
> > Yes, because it is a Meta-LVM, not an actualy inplementation.
> > I _really_ want something like that in 2.5 - but not this horrible IBM
> > implementation.
> 
> Maybe you can help them work on it?

If they stop ignoring me - sure.

> They have recently just redone a lot
> of the code, partly based on input from Andrew Clausen.  I don't see any
> other similar projects out there, and I think it is a waste of effort to
> complain about work that is done rather than fix it.  I tried for a long
> time (while it was still my job to do so) to fix the current Linux-LVM
> code, and I only had very minimal impact.  Even so, Linux-LVM will never
> become a Meta-LVM without AT LEAST as much "mess" as EVMS, and probably
> will contain a lot more.

Linux-LVM doesn't even try to be a "Meta-LVM".

> 
> IBM is at least doing something about this by putting their code where
> their mouth is.  Nothing is ever perfect.  Consider MD RAID - it isn't
> even compatible between "stock" 2.2 and 2.2+Mingo-0.9RAID patches (which
> is one reason why Alan never accepted the 0.9 MD RAID into 2.2, despite the
> fact that ALL distros used the 0.9 MD RAID patches).

It's a different issue.  For 2.4 ti sould be very easy to support both,
2.2 is missing a generic block remapping interface.

> > Nope - I'm currently working on implementing VxVM support, and I have
> > to redo all the RAID stuff because it is so incomaptible.
> 
> The question is - will the VxVM support be yet ANOTHER separate code base
> in the kernel?

Of course I plug into one of the many generic volume managment frameworks
that are available - that's why we have this thread, heh?

> 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

> > If you have a design to share the RAID engine for very different layouts:
> > nice - but I don'T see the relation to EVMS.
> 
> No, I can't say I do - it was purely speculation based on the concept that
> RAID-1 and RAID-5 are GENERALLY the same concept.  Maybe the reason VxVM
> is so different is that it also incorporates "LVM" style function as well?

Yes.  It has a completly different layering.  FreeBSD Vinum has a structure
that is somewhat similar if you want to take a look at another opensource
project.

> Note that NT-LDM ALSO has RAID-0/1/5 modes (not yet supported by the LDM
> driver) which will eventually need support.  Do you want the number of RAID
> implementations in the kernel to grow without bound, or rather try and
> consolidate them (where possible) into a generic interface like EVMS?

You forgot ATA fakeraid by arjan :)

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: IBMs LVM?

[Christoph Hellwig]

Ok, enough work done - back to the flamefests :)

On Fri, Sep 14, 2001 at 04:55:31PM -0500, Kevin Corry wrote:
> 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".

That's my position as well, good.

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


Noe need for FUD here.  Please recall the 

	Subject: Re: [Evms] Questions about portability

thread in 01/2001, specificly my post

	Message-ID: <20010111142355.A10524@caldera.de>

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

Blarg.  All this this code is obsolete but you can force it back in stuff
will make Linux as unmaintainable and bloated as the commercial UNICEs.

If we have a nice, leight-weight abstraction there is no reason to not use
it.  Of course your code is currently neither small nor nicely abstracted..

Anyway, I will get my design for improved block device stacking and unified
partition discovery back from the attic and implement a protopy ontop of
the bio patchset.  I'll Cc my ennouncement to evms-devel, you're free to
layer ontop if you want.

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

3700 lines of 2800?  My current CVS sais it's about 2800.

> 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 the core MD code being more than another few k-lines, and hopefully a
> nearly straight port of the personality modules.

Currently the md codee is about 10k LOC, that includes raid0/1/4/5, linear
and mutlipathing and high-speed checksumming code

	Christoph

Re: IBMs LVM?

[Andreas Dilger]

On Sep 20, 2001  13:57 +0200, Christoph Hellwig wrote:
> Anyway, I will get my design for improved block device stacking and unified
> partition discovery back from the attic and implement a protopy ontop of
> the bio patchset.  I'll Cc my ennouncement to evms-devel, you're free to
> layer ontop if you want.

Just FYI (in case you haven't seen it) the LVM folks are working on
something like this in their "LVM2" repository.  I've been seeing
the CVS commit messages, but have not actually taken a look at the
code yet, so I can't comment on it but it may save you some effort.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: IBMs LVM?

[Steven Whitehouse]

Hi,

Just a quick update on whats going on with the new LVM stuff.... Joe had
announced a release a little while ago with some initial code which he
has been working on for a while. I've been continuing that (along with
various other Sistina people doing testing) to make the initial code more
robust and finalise the kernel/user interface.

I hope that by the end of next week we'll have the new filesystem based
interface finished and tested at which point we'll announce it again as
a suitable time for interested parties to have a look. Feel free to check
out the CVS in the mean time though :-)

In order for the driver to be useful, we need code to read metadata from
disks and write suitable tables to drive the device mapper. We are already
working on this next step but will focus more upon it when the driver is
finished.

Please send any comments or patches to the linux-lvm list,

Thanks,

Steve.

> 
> On Sep 20, 2001  13:57 +0200, Christoph Hellwig wrote:
> > Anyway, I will get my design for improved block device stacking and unified
> > partition discovery back from the attic and implement a protopy ontop of
> > the bio patchset.  I'll Cc my ennouncement to evms-devel, you're free to
> > layer ontop if you want.
> 
> Just FYI (in case you haven't seen it) the LVM folks are working on
> something like this in their "LVM2" repository.  I've been seeing
> the CVS commit messages, but have not actually taken a look at the
> code yet, so I can't comment on it but it may save you some effort.
> 
> Cheers, Andreas
> --
> Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
>                  \  would they cancel out, leaving him still hungry?"
> http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
> 
> -
> 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/
> 

Re: IBMs LVM ?

[Jes Sorensen]

>>>>> "Christoph" == Christoph Hellwig <hch@caldera.de> writes:

Christoph> On Tue, Sep 11, 2001 at 11:57:13AM -0600, Andreas Dilger
Christoph> wrote:
>> Do you have a specific complaint?  The current LVM kernel code
>> isn't all that robust either (and the user-space code is not very
>> pretty).

Christoph> Please take a barf-bag, look at the code, look at the
Christoph> unneded abstrations, look at the uneeded interfaces, look
Christoph> at the code-duplication, look at the over-engineering.

At least the IBM guys seem interested in listening and taking
code/suggestions from the community. There was a fairly productive BOF
at OLS a couple of months ago. Thats a lot more than we can say about
the current LVM.

Jes

Re: IBMs LVM ?

[Alan Cox]

> At least the IBM guys seem interested in listening and taking
> code/suggestions from the community. There was a fairly productive BOF
> at OLS a couple of months ago. Thats a lot more than we can say about
> the current LVM.

I've been taking LVM patches into -ac via Joe and the impression I get
is that they are working sanely and sensibly towards cleaning up the
existing LVM code. It certainly isnt a trivial job to take any piece of
code and make it excellent, and I am sure they would benefit from productive
help and patches

Alan