[linux-lvm] [ANNOUNCE] LVM reimplementation ready for beta testing

[linux-lvm] [ANNOUNCE] LVM reimplementation ready for beta testing

[Joe Thornber]

All,

Sistina is pleased to announce that the LVM2 software is ready for
beta testing.

This is a complete reimplementation of the existing LVM system, both
driver and userland tools.

We encourage you to give it a try and feed back your test results,
bug-fixes, enhancement requests etc. through the normal lists
linux-lvm@sistina.com and lvm-devel@sistina.com.

The new kernel driver (known as "device-mapper") supports volume
management in general and is no longer Linux LVM specific.
As such it is a separate package from LVM2 which you will need
to download and install before building LVM2.

 ftp://ftp.sistina.com/pub/LVM2/device-mapper/device-mapper-beta1.tgz


The userland tools are available from here:

 ftp://ftp.sistina.com/pub/LVM2/tools/LVM2.0-beta1.tgz


This release does not support snapshots or pvmove.  These features
will go into a subsequent beta release, hopefully within the next
fortnight.

This is Beta software which is *not* meant to be running on your
production systems.  If necessary, keep backups of your data and LVM
metadata (/etc/lvmconf/*).


We look forward to your feedback.


The Sistina LVM team:

      Patrick Caulfield,
      Alasdair Kergon,
      Heinz Mauelshagen,
      Joe Thornber

[ANNOUNCE] LVM reimplementation ready for beta testing

[Joe Thornber]

All,

Sistina is pleased to announce that the LVM2 software is ready for
beta testing.

This is a complete reimplementation of the existing LVM system, both
driver and userland tools.

We encourage you to give it a try and feed back your test results,
bug-fixes, enhancement requests etc. through the normal lists
linux-lvm@sistina.com and lvm-devel@sistina.com.

The new kernel driver (known as "device-mapper") supports volume
management in general and is no longer Linux LVM specific.
As such it is a separate package from LVM2 which you will need
to download and install before building LVM2.

 ftp://ftp.sistina.com/pub/LVM2/device-mapper/device-mapper-beta1.tgz


The userland tools are available from here:

 ftp://ftp.sistina.com/pub/LVM2/tools/LVM2.0-beta1.tgz


This release does not support snapshots or pvmove.  These features
will go into a subsequent beta release, hopefully within the next
fortnight.

This is Beta software which is *not* meant to be running on your
production systems.  If necessary, keep backups of your data and LVM
metadata (/etc/lvmconf/*).


We look forward to your feedback.


The Sistina LVM team:

      Patrick Caulfield,
      Alasdair Kergon,
      Heinz Mauelshagen,
      Joe Thornber

[linux-lvm] Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Andreas Dilger]

On Jan 30, 2002  20:22 +0000, Joe Thornber wrote:
> Sistina is pleased to announce that the LVM2 software is ready for
> beta testing.
> 
> This is a complete reimplementation of the existing LVM system, both
> driver and userland tools.

What is the current and future licensing of the LVM2 code?  Given the
GFS events, I think people will be hesitant to accept an all-Sistina
reimplementation of LVM.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Andreas Dilger]

On Jan 30, 2002  20:22 +0000, Joe Thornber wrote:
> Sistina is pleased to announce that the LVM2 software is ready for
> beta testing.
> 
> This is a complete reimplementation of the existing LVM system, both
> driver and userland tools.

What is the current and future licensing of the LVM2 code?  Given the
GFS events, I think people will be hesitant to accept an all-Sistina
reimplementation of LVM.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

[linux-lvm] Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Jim McDonald]

On Wed, 2002-01-30 at 21:54, Andreas Dilger wrote:
> On Jan 30, 2002  20:22 +0000, Joe Thornber wrote:
> > Sistina is pleased to announce that the LVM2 software is ready for
> > beta testing.
> > 
> > This is a complete reimplementation of the existing LVM system, both
> > driver and userland tools.
> 
> What is the current and future licensing of the LVM2 code?  Given the
> GFS events, I think people will be hesitant to accept an all-Sistina
> reimplementation of LVM.

Also, does/where does this fit in with EVMS?

Cheers,
Jim.
-- 
Jim McDonald - Jim@mcdee.net

Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Jim McDonald]

On Wed, 2002-01-30 at 21:54, Andreas Dilger wrote:
> On Jan 30, 2002  20:22 +0000, Joe Thornber wrote:
> > Sistina is pleased to announce that the LVM2 software is ready for
> > beta testing.
> > 
> > This is a complete reimplementation of the existing LVM system, both
> > driver and userland tools.
> 
> What is the current and future licensing of the LVM2 code?  Given the
> GFS events, I think people will be hesitant to accept an all-Sistina
> reimplementation of LVM.

Also, does/where does this fit in with EVMS?

Cheers,
Jim.
-- 
Jim McDonald - Jim@mcdee.net

[linux-lvm] Re: [ANNOUNCE] LVM reimplementation ready for beta testing

[Lars Kellogg-Stedman]

> Also, does/where does this fit in with EVMS?

It doesn't :).  They're essentially competing implementations that offer 
similar functionality.  I've been running the EVMS stuff for a while 
now, and it's (a) been pretty darn solid, and (b) is completely 
compatible with LVM1 on disk.

The next release of EVMS should also allow you to replace the standard 
MD subsystem (RAID 0/1/5) with EVMS.

I think that, in general, competition is good.  A stable, robust, and 
flexible logical volume implementation is a good thing, and we'll 
probably get there faster with two groups acting as inspirations for 
each other.

Cheers,

-- Lars

Re: [linux-lvm] Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Joe Thornber]

On Wed, Jan 30, 2002 at 10:03:40PM +0000, Jim McDonald wrote:
> Also, does/where does this fit in with EVMS?

EVMS differs from us in that they seem to be trying to move the whole
application into the kernel, whereas we've taken the opposite route
and stripped down the kernel side to just provide services.

This is fine, I think there's room for both projects.  But it is worth
noting that EVMS could be changed to use device-mapper for it's low
level functionality.  That way they could take advantage of the cool
work we're doing with snapshots and pvmove, and we could take
advantage of having more eyes on the core driver.

LVM2 may not seem that exciting initially, since the first release is
just concentrating on reproducing LVM1 functionality.  But a lot of
the reason for this rewrite is to enable us to add in the new features
that we want (such as a transaction based disk format).  It's on this
new feature list that we'll be mainly competing with EVMS.

- Joe

Re: [linux-lvm] Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[James Hawtin]

Licencing is important to me, too. Also is it pv/lv compatible with lvm 1
or is it system rebuild time.....

James

Re: [linux-lvm] Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Heinz J . Mauelshagen]

On Wed, Jan 30, 2002 at 10:36:10PM +0000, James Hawtin wrote:
> Licencing is important to me, too. Also is it pv/lv compatible with lvm 1
> or is it system rebuild time.....

LVM2 supports the existing LVM1 on disk metadata format and will support another
so called format2 soon which has enhanced metadata redundancy and transaction 
oriented updates in order to largely reduce the likelyhood of inacessable
VGs and metadata restores.

IOW: it will make LVM more insensible to hardware flaws.


> 
> James
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

Regards,
Heinz    -- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Joe Thornber]

On Wed, Jan 30, 2002 at 02:54:08PM -0700, Andreas Dilger wrote:
> On Jan 30, 2002  20:22 +0000, Joe Thornber wrote:
> > Sistina is pleased to announce that the LVM2 software is ready for
> > beta testing.
> > 
> > This is a complete reimplementation of the existing LVM system, both
> > driver and userland tools.
> 
> What is the current and future licensing of the LVM2 code?  Given the
> GFS events, I think people will be hesitant to accept an all-Sistina
> reimplementation of LVM.


LVM2 is GPL/LGPL-licensed - just like the original version of LVM.
This means the whole Linux community benefits from this aspect of
Sistina's work.  The device-mapper and LVM2 packages will *always* be
GPL/LGPL.

As those who have been following LVM development closely will be aware,
the decision to rewrite was taken for sound technical - not licensing -
reasons, and of course we welcome and encourage contributions to LVM2
from outside Sistina.

- Joe

[linux-lvm] Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Joe Thornber]

On Wed, Jan 30, 2002 at 02:54:08PM -0700, Andreas Dilger wrote:
> On Jan 30, 2002  20:22 +0000, Joe Thornber wrote:
> > Sistina is pleased to announce that the LVM2 software is ready for
> > beta testing.
> > 
> > This is a complete reimplementation of the existing LVM system, both
> > driver and userland tools.
> 
> What is the current and future licensing of the LVM2 code?  Given the
> GFS events, I think people will be hesitant to accept an all-Sistina
> reimplementation of LVM.


LVM2 is GPL/LGPL-licensed - just like the original version of LVM.
This means the whole Linux community benefits from this aspect of
Sistina's work.  The device-mapper and LVM2 packages will *always* be
GPL/LGPL.

As those who have been following LVM development closely will be aware,
the decision to rewrite was taken for sound technical - not licensing -
reasons, and of course we welcome and encourage contributions to LVM2
from outside Sistina.

- Joe

[linux-lvm] Re: [ANNOUNCE] LVM reimplementation ready for beta testing

[Daniel Phillips]

On January 30, 2002 09:22 pm, Joe Thornber wrote:
> The new kernel driver (known as "device-mapper") supports volume
> management in general and is no longer Linux LVM specific.
> As such it is a separate package from LVM2 which you will need
> to download and install before building LVM2.
> 
>  ftp://ftp.sistina.com/pub/LVM2/device-mapper/device-mapper-beta1.tgz

Hi, thanks a lot for this fine gift.  One small point: I downloaded these
files right away of course, then I renamed device-mapper-beta1.tgz as
LVM2-mapper-beta1.tgz, so I'd be able to find these things in my (very
full) download directory.  What do you think about doing it that way at
source?

> The userland tools are available from here:
> 
>  ftp://ftp.sistina.com/pub/LVM2/tools/LVM2.0-beta1.tgz

-- 
Daniel

Re: [ANNOUNCE] LVM reimplementation ready for beta testing

[Daniel Phillips]

On January 30, 2002 09:22 pm, Joe Thornber wrote:
> The new kernel driver (known as "device-mapper") supports volume
> management in general and is no longer Linux LVM specific.
> As such it is a separate package from LVM2 which you will need
> to download and install before building LVM2.
> 
>  ftp://ftp.sistina.com/pub/LVM2/device-mapper/device-mapper-beta1.tgz

Hi, thanks a lot for this fine gift.  One small point: I downloaded these
files right away of course, then I renamed device-mapper-beta1.tgz as
LVM2-mapper-beta1.tgz, so I'd be able to find these things in my (very
full) download directory.  What do you think about doing it that way at
source?

> The userland tools are available from here:
> 
>  ftp://ftp.sistina.com/pub/LVM2/tools/LVM2.0-beta1.tgz

-- 
Daniel

Re: [linux-lvm] Re: [ANNOUNCE] LVM reimplementation ready for beta testing

[Heinz J . Mauelshagen]

On Thu, Jan 31, 2002 at 02:53:10AM +0100, Daniel Phillips wrote:
> On January 30, 2002 09:22 pm, Joe Thornber wrote:
> > The new kernel driver (known as "device-mapper") supports volume
> > management in general and is no longer Linux LVM specific.
> > As such it is a separate package from LVM2 which you will need
> > to download and install before building LVM2.
> > 
> >  ftp://ftp.sistina.com/pub/LVM2/device-mapper/device-mapper-beta1.tgz
> 
> Hi, thanks a lot for this fine gift.  One small point: I downloaded these
> files right away of course, then I renamed device-mapper-beta1.tgz as
> LVM2-mapper-beta1.tgz, so I'd be able to find these things in my (very
> full) download directory.  What do you think about doing it that way at
> source?

Well, as said in the annoucement the device-mapper is no longer Linux LVM
specific and therefore we choosed to give it a name without any 'LVM' substring
in its name. device-mapper is just a package LVM2 needs to run beside others
like linux-kernel ;-)

> 
> > The userland tools are available from here:
> > 
> >  ftp://ftp.sistina.com/pub/LVM2/tools/LVM2.0-beta1.tgz
> 
> -- 
> Daniel
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [ANNOUNCE] LVM reimplementation ready for beta testing

[christophe barbé]

[-- Attachment #1: Type: text/plain, Size: 870 bytes --]

On Wed, Jan 30, 2002 at 08:22:54PM +0000, Joe Thornber wrote:
> The new kernel driver (known as "device-mapper") supports volume
> management in general and is no longer Linux LVM specific.
> As such it is a separate package from LVM2 which you will need
> to download and install before building LVM2.
> 
>  ftp://ftp.sistina.com/pub/LVM2/device-mapper/device-mapper-beta1.tgz

I was so curious of the new license that could have been created by sistina
that I try to download the driver but it seems not possible at this
time.

So let me guess ... SPL2 ?
Oh no, the sistina way, you want some free debugging before switching
from GPL to SPL.

Christophe

-- 
Christophe Barbé <christophe.barbe@ufies.org>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

As every cat owner knows, nobody owns a cat.
--Ellen Perry Berkeley

[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]

Re: [ANNOUNCE] LVM reimplementation ready for beta testing

[Heinz J . Mauelshagen]

On Wed, Jan 30, 2002 at 08:01:20PM -0500, christophe barbé wrote:
> On Wed, Jan 30, 2002 at 08:22:54PM +0000, Joe Thornber wrote:
> > The new kernel driver (known as "device-mapper") supports volume
> > management in general and is no longer Linux LVM specific.
> > As such it is a separate package from LVM2 which you will need
> > to download and install before building LVM2.
> > 
> >  ftp://ftp.sistina.com/pub/LVM2/device-mapper/device-mapper-beta1.tgz
> 
> I was so curious of the new license that could have been created by sistina
> that I try to download the driver but it seems not possible at this
> time.
> 
> So let me guess ... SPL2 ?
> Oh no, the sistina way, you want some free debugging before switching
> from GPL to SPL.

Thanks for these untenable guesses ;-)

LVM2 and the device-mapper are GPL/LGPL.

Sistina decided to offer this to the community and to keep it under
the FSF licenses.

This has been stated on the Linux LVM lists before.

OTOH we need to survive as a company and therefore will implement
comercial enhancements which will BTW enable us to do support and
further development of the above free software.

> 
> Christophe
> 
> -- 
> Christophe Barbé <christophe.barbe@ufies.org>
> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E
> 
> As every cat owner knows, nobody owns a cat.
> --Ellen Perry Berkeley


Regards,
Heinz    -- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [ANNOUNCE] LVM reimplementation ready for beta testing

[Jeff Garzik]

On Thu, Jan 31, 2002 at 01:45:33PM +0100, Heinz J . Mauelshagen wrote:
> LVM2 and the device-mapper are GPL/LGPL.

Could you clarify the meaning of "GPL/LGPL"?  Are certain parts GPL and
other parts LGPL?  If so, which parts?

	jeff

Re: [ANNOUNCE] LVM reimplementation ready for beta testing

[Heinz J . Mauelshagen]

On Thu, Jan 31, 2002 at 01:42:25PM -0500, Jeff Garzik wrote:
> On Thu, Jan 31, 2002 at 01:45:33PM +0100, Heinz J . Mauelshagen wrote:
> > LVM2 and the device-mapper are GPL/LGPL.
> 
> Could you clarify the meaning of "GPL/LGPL"?  Are certain parts GPL and
> other parts LGPL?  If so, which parts?

The LVM2 sofware no longer uses a particular driver which is just
usable for its own purpose.
It rather accesses a different, so-called 'device-mapper' driver, which
implements a generic volume management service for the Linux kernel by
supporting arbitray mappings of address ranges to underlying block devices.
Because this is a generic service rather than an application within the kernel,
it is open to be used by multiple LVM implementations (for eg. EVMS could be
ported to use it :-)

The device-mapper driver is under the GPL and our Beta1 release dated Wednesday,
which included the LVM2 tools as well, supports 2.4 kernels. We are aiming to
get it integrated into the stock kernel and are implementing the necessary
changes (bio interface) for 2.5 now.
We released a device-mapper library (implements a generic API for the
device-mapper) which is under the LGPL with it.

The LVM2 tools have a library with routines to for eg. access the
device-mapper library, deal with LVM metadata (VGDA), support different
metadata formats and offer configuration file support which is under the
LGPL as well.
The tools themselves (vgcreate, lvcreate, ...) are under the GPL.

IOW:

GPL				LGPL
-----------------------------   ------------------------------
LVM2 tools			LVM2 library
device-mapper driver		device-mapper library

> 
> 	jeff
> 
> 

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [ANNOUNCE] LVM reimplementation ready for beta testing

[Bill Davidsen]

On Fri, 1 Feb 2002, Heinz J . Mauelshagen wrote:

> The LVM2 sofware no longer uses a particular driver which is just
> usable for its own purpose.
> It rather accesses a different, so-called 'device-mapper' driver, which
> implements a generic volume management service for the Linux kernel by
> supporting arbitray mappings of address ranges to underlying block devices.
> Because this is a generic service rather than an application within the kernel,
> it is open to be used by multiple LVM implementations (for eg. EVMS could be
> ported to use it :-)

Interesting concept, but something like the "smitZ" interface to RAID and
sizing would be really nice to reduce training effort. Since IBM is
pushing Linux, take this as a HINT.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [ANNOUNCE] LVM reimplementation ready for beta testing

[Heinz J . Mauelshagen]

On Mon, Feb 04, 2002 at 05:16:27PM -0500, Bill Davidsen wrote:
> On Fri, 1 Feb 2002, Heinz J . Mauelshagen wrote:
> 
> > The LVM2 sofware no longer uses a particular driver which is just
> > usable for its own purpose.
> > It rather accesses a different, so-called 'device-mapper' driver, which
> > implements a generic volume management service for the Linux kernel by
> > supporting arbitray mappings of address ranges to underlying block devices.
> > Because this is a generic service rather than an application within the kernel,
> > it is open to be used by multiple LVM implementations (for eg. EVMS could be
> > ported to use it :-)
> 
> Interesting concept, but something like the "smitZ" interface to RAID and
> sizing would be really nice to reduce training effort. Since IBM is
> pushing Linux, take this as a HINT.

Hint is to user interface only or to in kernel ones as well?

> 
> -- 
> bill davidsen <davidsen@tmr.com>
>   CTO, TMR Associates, Inc
> Doing interesting things with little computers since 1979.

-- 

Regards,
Heinz    -- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Steve Pratt]

Joe Thornber wrote:
>On Wed, Jan 30, 2002 at 10:03:40PM +0000, Jim McDonald wrote:
>> Also, does/where does this fit in with EVMS?

>EVMS differs from us in that they seem to be trying to move the whole
>application into the kernel,

No, not really.  We only put in the kernel the things that make sense to be
in the kernel, discovery logic, ioctl support, I/O path.  All configuration
is handled in user space.

> whereas we've taken the opposite route
>and stripped down the kernel side to just provide services.

Then why does snapshot.c in device mapper have a read_metadata function
which populates the exception table from on disk metadata?  Seems like you
agree with us that having metadata knowledge in the kernel is a GOOD thing.

>This is fine, I think there's room for both projects.  But it is worth
>noting that EVMS could be changed to use device-mapper for it's low
>level functionality.  That way they could take advantage of the cool
>work we're doing with snapshots and pvmove, and we could take
>advantage of having more eyes on the core driver.

Since device_mapper does not support in kernel discovery, and EVMS relies
on this, it would be very difficult to change EVMS to use device_mapper.
Besides, EVMS already has all the capabilities provided by device mapper,
including a complete LVM1 compatibility package.

>LVM2 may not seem that exciting initially, since the first release is
>just concentrating on reproducing LVM1 functionality.  But a lot of
>the reason for this rewrite is to enable us to add in the new features
>that we want (such as a transaction based disk format).  It's on this
>new feature list that we'll be mainly competing with EVMS.

Why compete, come on over and help us :-)

Steve


EVMS Development - http://www.sf.net/projects/evms
Linux Technology Center - IBM Corporation
(512) 838-9763  EMAIL: SLPratt@US.IBM.COM

Re: [linux-lvm] Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Steve Pratt]

Joe Thornber wrote:
>On Wed, Jan 30, 2002 at 10:03:40PM +0000, Jim McDonald wrote:
>> Also, does/where does this fit in with EVMS?

>EVMS differs from us in that they seem to be trying to move the whole
>application into the kernel,

No, not really.  We only put in the kernel the things that make sense to be
in the kernel, discovery logic, ioctl support, I/O path.  All configuration
is handled in user space.

> whereas we've taken the opposite route
>and stripped down the kernel side to just provide services.

Then why does snapshot.c in device mapper have a read_metadata function
which populates the exception table from on disk metadata?  Seems like you
agree with us that having metadata knowledge in the kernel is a GOOD thing.

>This is fine, I think there's room for both projects.  But it is worth
>noting that EVMS could be changed to use device-mapper for it's low
>level functionality.  That way they could take advantage of the cool
>work we're doing with snapshots and pvmove, and we could take
>advantage of having more eyes on the core driver.

Since device_mapper does not support in kernel discovery, and EVMS relies
on this, it would be very difficult to change EVMS to use device_mapper.
Besides, EVMS already has all the capabilities provided by device mapper,
including a complete LVM1 compatibility package.

>LVM2 may not seem that exciting initially, since the first release is
>just concentrating on reproducing LVM1 functionality.  But a lot of
>the reason for this rewrite is to enable us to add in the new features
>that we want (such as a transaction based disk format).  It's on this
>new feature list that we'll be mainly competing with EVMS.

Why compete, come on over and help us :-)

Steve


EVMS Development - http://www.sf.net/projects/evms
Linux Technology Center - IBM Corporation
(512) 838-9763  EMAIL: SLPratt@US.IBM.COM

Re: [linux-lvm] Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Joe Thornber]

On Thu, Jan 31, 2002 at 01:52:29PM -0600, Steve Pratt wrote:
> Joe Thornber wrote:
> >On Wed, Jan 30, 2002 at 10:03:40PM +0000, Jim McDonald wrote:
> >> Also, does/where does this fit in with EVMS?
> 
> >EVMS differs from us in that they seem to be trying to move the whole
> >application into the kernel,
> 
> No, not really.  We only put in the kernel the things that make sense to be
> in the kernel, discovery logic, ioctl support, I/O path.  All configuration
> is handled in user space.

There's still a *lot* of code in there; > 26,000 lines in fact.
Whereas device-mapper weighs in at ~2,600 lines.  This is just because
you've decided to take a different route from us, you may be proven to
be correct.

> > whereas we've taken the opposite route
> >and stripped down the kernel side to just provide services.
> 
> Then why does snapshot.c in device mapper have a read_metadata function
> which populates the exception table from on disk metadata?  Seems like you
> agree with us that having metadata knowledge in the kernel is a GOOD thing.

In the case of snapshots the exception data has to be written by the
kernel for performance reasons, as you know.  This is still a far cry
from understanding the LVM1 metadata format.

> Since device_mapper does not support in kernel discovery, and EVMS relies
> on this, it would be very difficult to change EVMS to use device_mapper.

So do the discovery on the EVMS side, and then pass the tables across
to device-mapper to activate the LV's.

> Why compete, come on over and help us :-)

I would like the two projects to help each other, but not to the point
where one group of people has to say 'you are completely right, we
will stop developing our project'.  It's unlikely that either of us is
100% correct; but I do think device-mapper splits off a nice chunk of
services that is useful to *all* people who want to do volume
management.  As such I see that as one area where we may eventually
work together.

Similarly I expect to be providing an *optional* kernel module for LVM
users who wish to do in kernel discovery of a root LV, so if the EVMS
team has managed to get a nice generic way of iterating block devices
etc.  into the kernel, we would be able to take advantage of that.
Are you trying to break out functionality so it benefits other Linux
projects ? or is EVMS just one monolithic application embedded in the
kernel ?

- Joe

Re: [linux-lvm] Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Joe Thornber]

On Thu, Jan 31, 2002 at 01:52:29PM -0600, Steve Pratt wrote:
> Joe Thornber wrote:
> >On Wed, Jan 30, 2002 at 10:03:40PM +0000, Jim McDonald wrote:
> >> Also, does/where does this fit in with EVMS?
> 
> >EVMS differs from us in that they seem to be trying to move the whole
> >application into the kernel,
> 
> No, not really.  We only put in the kernel the things that make sense to be
> in the kernel, discovery logic, ioctl support, I/O path.  All configuration
> is handled in user space.

There's still a *lot* of code in there; > 26,000 lines in fact.
Whereas device-mapper weighs in at ~2,600 lines.  This is just because
you've decided to take a different route from us, you may be proven to
be correct.

> > whereas we've taken the opposite route
> >and stripped down the kernel side to just provide services.
> 
> Then why does snapshot.c in device mapper have a read_metadata function
> which populates the exception table from on disk metadata?  Seems like you
> agree with us that having metadata knowledge in the kernel is a GOOD thing.

In the case of snapshots the exception data has to be written by the
kernel for performance reasons, as you know.  This is still a far cry
from understanding the LVM1 metadata format.

> Since device_mapper does not support in kernel discovery, and EVMS relies
> on this, it would be very difficult to change EVMS to use device_mapper.

So do the discovery on the EVMS side, and then pass the tables across
to device-mapper to activate the LV's.

> Why compete, come on over and help us :-)

I would like the two projects to help each other, but not to the point
where one group of people has to say 'you are completely right, we
will stop developing our project'.  It's unlikely that either of us is
100% correct; but I do think device-mapper splits off a nice chunk of
services that is useful to *all* people who want to do volume
management.  As such I see that as one area where we may eventually
work together.

Similarly I expect to be providing an *optional* kernel module for LVM
users who wish to do in kernel discovery of a root LV, so if the EVMS
team has managed to get a nice generic way of iterating block devices
etc.  into the kernel, we would be able to take advantage of that.
Are you trying to break out functionality so it benefits other Linux
projects ? or is EVMS just one monolithic application embedded in the
kernel ?

- Joe