[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

[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: [Evms-devel] Re: [linux-lvm] Re: [lvm-devel] [ANNOUNCE] LVM reimplementation ready for beta testing

[Arjan van de Ven]

On Thu, Jan 31, 2002 at 12:52:11PM +0000, Joe Thornber wrote:
> 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.

There is one thing that might spoil the device-mapper "just simple stuff
only" thing: moving active volumes around. Doing that in userspace reliably
is impossible and basically needs to be done in kernelspace (it's an
operation comparable with raid1 resync, a not even that hard in kernel
space). However, that sort of automatically requires kernelspace to know
about volumes, and from there it's a small step....

Greetings,
   Arjan van de Ven

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

[Joe Thornber]

On Fri, Feb 01, 2002 at 04:55:18AM -0500, Arjan van de Ven wrote:
> There is one thing that might spoil the device-mapper "just simple stuff
> only" thing: moving active volumes around. Doing that in userspace reliably
> is impossible and basically needs to be done in kernelspace (it's an
> operation comparable with raid1 resync, a not even that hard in kernel
> space). However, that sort of automatically requires kernelspace to know
> about volumes, and from there it's a small step....

I think you're talking about pvmove and friends, in which case I hope
the description below helps.

- Joe



Let's say we have an LV, made up of three segments of different PV's,
I've also added in the device major:minor as this will be useful
later:

+-----------------------------+
|  PV1     |   PV2   |   PV3  | 254:3
+----------+---------+--------+


Now our hero decides to PV move PV2 to PV4:

1. Suspend our LV (254:3), this starts queueing all io, and flushes
   all pending io.  Once the suspend has completed we are free to change
   the mapping table.

2. Set up *another* (254:4) device with the mapping table of our LV.

3. Load a new mapping table into (254:3) that has identity targets for
   parts that aren't moving, and a mirror target for parts that are.

4. Unsuspend (254:3)

So now we have:
                           destination of copy
               +--------------------->--------------+
               |                                    |
+-----------------------------+               + -----------+
| Identity | mirror  | Ident. | 254:3         |    PV4     |
+----------+---------+--------+               +------------+
     |         |         |
     \/        \/        \/
+-----------------------------+
|  PV1     |   PV2   |   PV3  | 254:4
+----------+---------+--------+

Any writes to segment2 of the LV get intercepted by the mirror target
who checks that that chunk has been copied to the new destination, if
it hasn't it queues the initial copy and defers the current io until
it has finished.  Then the current io is written to *both* PV2 and the
PV4.

5. When the copying has completed 254:3 is suspended/pending flushed.

6. 254:4 is taken down

7. metadata is updated on disk

8. 254:3 has new mapping table loaded:

+-----------------------------+
|  PV1     |   PV4   |   PV3  | 254:3
+----------+---------+--------+

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

[Arjan van de Ven]

On Thu, Jan 31, 2002 at 01:09:13PM +0000, Joe Thornber wrote:
> 
> Now our hero decides to PV move PV2 to PV4:
> 
> 1. Suspend our LV (254:3), this starts queueing all io, and flushes
>    all pending io. 

But "flushes all pending io" is *far* from trivial. there's no current
kernel functionality for this, so you'll have to do "weird shit" that will
break easy and often.

Also "suspending" is rather dangerous because it can deadlock the machine
(think about the VM needing to write back dirty data on this LV in order to
 make memory available for your move)...

Greetings,
  Arjan van de Ven

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

[Joe Thornber]

On Fri, Feb 01, 2002 at 05:12:51AM -0500, Arjan van de Ven wrote:
> On Thu, Jan 31, 2002 at 01:09:13PM +0000, Joe Thornber wrote:
> > 
> > Now our hero decides to PV move PV2 to PV4:
> > 
> > 1. Suspend our LV (254:3), this starts queueing all io, and flushes
> >    all pending io. 
> 
> But "flushes all pending io" is *far* from trivial. there's no current
> kernel functionality for this, so you'll have to do "weird shit" that will
> break easy and often.

Here's the weird shit.  If you can see how to break it, I'd like to
know.

Whenever the dm driver maps a buffer_head, I increment a 'pending'
counter for that device, and hook the bh->b_end_io, bh->b_private
function so that this counter is decremented when the io completes.
This doesn't work with ext3 on 2.4 kernels since ext3 believes the
b_private pointer is for general filesystem use rather than just
b_end_io, however Stephen Tweedie and I have been discussing ways to
get round this.  On 2.5 this works fine since the bio->bi_private
isn't abused in this way.

> Also "suspending" is rather dangerous because it can deadlock the machine
> (think about the VM needing to write back dirty data on this LV in order to
>  make memory available for your move)...

You are correct, this is the main flaw IMO with the LVM1 version of
pvmove (which was userland with locking on a per extent basis).

However for LVM2 the device will only be suspended while a table
is loaded, *not* while the move takes place.  I will however allocate
the struct deferred_io objects from a mempool in 2.5.

- Joe

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

[Alan Cox]

> But "flushes all pending io" is *far* from trivial. there's no current
> kernel functionality for this, so you'll have to do "weird shit" that will
> break easy and often.
> 
> Also "suspending" is rather dangerous because it can deadlock the machine
> (think about the VM needing to write back dirty data on this LV in order to
>  make memory available for your move)...

I don't think you need to suspend I/O except momentarily. I don't use LVM and
while I can't resize volumes I migrate them like this

	mdhotadd /dev/md1 /dev/newvolume

[wait for it to resync]

	mdhotremove /dev/md1 /dev/oldvolume

the situation here seems analogous. You never need to suspend I/O to the
volume until you actually kill it, by which time you can just skip the write
to the dead volume.

(The above procedure with ext3 does btw make a great backup system 8))

Alan