[linux-lvm] *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[linux-lvm] *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Heinz J . Mauelshagen]

Hi all,

with all the kind support of the community to stabilize the Linux Logical
Volume Manager, we are proud to announce the production level release 1.0.

A tarball is available now at

   <http://www.sistina.com/>

for download (Follow the "LVM 1.0" link).

This release contains minor changes to 0.9.1 Beta 8.

!!! YOU STILL NEED TO FOLLOW THE INSTRUCTIONS IN README.1ST !!!
See the CHANGELOG file contained in the tarball for further information.

We are still working together with Alan Cox on the integration of the
actual driver into vanilla. *Sorry* folks, we couldn't wait any longer ;-)

Feed back LVM related information to <linux-lvm@sistina.com>.

Thanks a lot for your support of LVM.

-- 

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

*** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Heinz J . Mauelshagen]

Hi all,

with all the kind support of the community to stabilize the Linux Logical
Volume Manager, we are proud to announce the production level release 1.0.

A tarball is available now at

   <http://www.sistina.com/>

for download (Follow the "LVM 1.0" link).

This release contains minor changes to 0.9.1 Beta 8.

!!! YOU STILL NEED TO FOLLOW THE INSTRUCTIONS IN README.1ST !!!
See the CHANGELOG file contained in the tarball for further information.

We are still working together with Alan Cox on the integration of the
actual driver into vanilla. *Sorry* folks, we couldn't wait any longer ;-)

Feed back LVM related information to <linux-lvm@sistina.com>.

Thanks a lot for your support of LVM.

-- 

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

[linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Kurt Garloff]

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

On Wed, Aug 15, 2001 at 05:56:59PM +0200, Heinz J . Mauelshagen wrote:
> with all the kind support of the community to stabilize the Linux Logical
> Volume Manager, we are proud to announce the production level release 1.0.
[...]
> This release contains minor changes to 0.9.1 Beta 8.
> 
> !!! YOU STILL NEED TO FOLLOW THE INSTRUCTIONS IN README.1ST !!!
> See the CHANGELOG file contained in the tarball for further information.
> 
> We are still working together with Alan Cox on the integration of the
> actual driver into vanilla. *Sorry* folks, we couldn't wait any longer ;-)

Is there finally a decent way to upgrade from 0.9.1b7?
Or is it still required to have multiple versions of the utils installed
just in order to be able to update from 0.9.1b7 to b8 (or 1.0)?

If yes, then I'd vote for not updating the kernel until this is fixed!

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, DE                                SCSI, Security

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

Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Kurt Garloff]

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

On Wed, Aug 15, 2001 at 05:56:59PM +0200, Heinz J . Mauelshagen wrote:
> with all the kind support of the community to stabilize the Linux Logical
> Volume Manager, we are proud to announce the production level release 1.0.
[...]
> This release contains minor changes to 0.9.1 Beta 8.
> 
> !!! YOU STILL NEED TO FOLLOW THE INSTRUCTIONS IN README.1ST !!!
> See the CHANGELOG file contained in the tarball for further information.
> 
> We are still working together with Alan Cox on the integration of the
> actual driver into vanilla. *Sorry* folks, we couldn't wait any longer ;-)

Is there finally a decent way to upgrade from 0.9.1b7?
Or is it still required to have multiple versions of the utils installed
just in order to be able to update from 0.9.1b7 to b8 (or 1.0)?

If yes, then I'd vote for not updating the kernel until this is fixed!

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, DE                                SCSI, Security

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

[linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Heinz J . Mauelshagen]

On Wed, Aug 15, 2001 at 06:25:48PM +0200, Kurt Garloff wrote:
> On Wed, Aug 15, 2001 at 05:56:59PM +0200, Heinz J . Mauelshagen wrote:
> > with all the kind support of the community to stabilize the Linux Logical
> > Volume Manager, we are proud to announce the production level release 1.0.
> [...]
> > This release contains minor changes to 0.9.1 Beta 8.
> > 
> > !!! YOU STILL NEED TO FOLLOW THE INSTRUCTIONS IN README.1ST !!!
> > See the CHANGELOG file contained in the tarball for further information.
> > 
> > We are still working together with Alan Cox on the integration of the
> > actual driver into vanilla. *Sorry* folks, we couldn't wait any longer ;-)
> 
> Is there finally a decent way to upgrade from 0.9.1b7?
> Or is it still required to have multiple versions of the utils installed
> just in order to be able to update from 0.9.1b7 to b8 (or 1.0)?

Well, as explained before on the lists we had an algorithm calculating
the offset to the first PE in place till 0.9.1 Beta 7.

Therefore, we *need* to run the installed version < LVM 0.9.1 Beta 8 to
retrieve that sector offset for all PVs and change the metadata to hold the
offset. No known way around this.

> 
> If yes, then I'd vote for not updating the kernel until this is fixed!

Well, we need to migrate the metadata in the future anyway once we want
to offer support for enhanced metadata reliability and redundancy.
We'll provide bidirectional migration tools for that then which will enable
the user to swicth back and forth between 2 installed LVM versions.

Let's keep the ball flat WRT to the migration path here.
We've got mails with positive LVM 0.9.1 Beta 8 upgrade reports and
no complaints TTBOMK.

> 
> Regards,
> -- 
> Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
> GPG key: See mail header, key servers         Linux kernel development
> SuSE GmbH, Nuernberg, DE                                SCSI, Security



-- 

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: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Heinz J . Mauelshagen]

On Wed, Aug 15, 2001 at 06:25:48PM +0200, Kurt Garloff wrote:
> On Wed, Aug 15, 2001 at 05:56:59PM +0200, Heinz J . Mauelshagen wrote:
> > with all the kind support of the community to stabilize the Linux Logical
> > Volume Manager, we are proud to announce the production level release 1.0.
> [...]
> > This release contains minor changes to 0.9.1 Beta 8.
> > 
> > !!! YOU STILL NEED TO FOLLOW THE INSTRUCTIONS IN README.1ST !!!
> > See the CHANGELOG file contained in the tarball for further information.
> > 
> > We are still working together with Alan Cox on the integration of the
> > actual driver into vanilla. *Sorry* folks, we couldn't wait any longer ;-)
> 
> Is there finally a decent way to upgrade from 0.9.1b7?
> Or is it still required to have multiple versions of the utils installed
> just in order to be able to update from 0.9.1b7 to b8 (or 1.0)?

Well, as explained before on the lists we had an algorithm calculating
the offset to the first PE in place till 0.9.1 Beta 7.

Therefore, we *need* to run the installed version < LVM 0.9.1 Beta 8 to
retrieve that sector offset for all PVs and change the metadata to hold the
offset. No known way around this.

> 
> If yes, then I'd vote for not updating the kernel until this is fixed!

Well, we need to migrate the metadata in the future anyway once we want
to offer support for enhanced metadata reliability and redundancy.
We'll provide bidirectional migration tools for that then which will enable
the user to swicth back and forth between 2 installed LVM versions.

Let's keep the ball flat WRT to the migration path here.
We've got mails with positive LVM 0.9.1 Beta 8 upgrade reports and
no complaints TTBOMK.

> 
> Regards,
> -- 
> Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
> GPG key: See mail header, key servers         Linux kernel development
> SuSE GmbH, Nuernberg, DE                                SCSI, Security



-- 

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

[linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Andrea Arcangeli]

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

On Wed, Aug 15, 2001 at 06:50:05PM +0200, Heinz Mauelshagen wrote:
> offset. No known way around this.

As said in the attached email (never got a reply about it yet btw)
there's definitely a way around it, there's no magic in the beta7
lvmtools, anything they can do can be done as well in the new lvmtools
if we want to (and I believe we want to). I understand you don't want to
clobber the core code with backwards compatibility cruft, but a new
backwards compatibility utility, even in a new directory to make obvious
nothing gets clobbered, could be developed and it would solve the
problem.

Andrea

[-- Attachment #2: Type: message/rfc822, Size: 4881 bytes --]

From: Andrea Arcangeli <andrea@suse.de>
To: lvm-devel@sistina.com
Subject: Re: [lvm-devel] *** Pre LVM 0.9.1 Beta 8 release test request ***
Date: Tue, 31 Jul 2001 16:35:33 +0200
Message-ID: <20010731163533.P30071@athlon.random>

On Tue, Jul 31, 2001 at 02:20:50PM +0100, Joe Thornber wrote:
> On Tue, Jul 31, 2001 at 03:13:17PM +0200, Andrea Arcangeli wrote:
> > On Tue, Jul 31, 2001 at 10:41:37AM +0100, Joe Thornber wrote:
> > > On Tue, Jul 31, 2001 at 11:25:14AM +0200, Andrea Arcangeli wrote:
> > > > then why don't you make a pvdisplay option in the new tools that allows
> > > > you to find where the PEs were positioned?
> > > 
> > > The PE location was being calculated, based on various constants such
> > > as BLOCK_SIZE (which varied through the beta series), only the
> > > currently installed tools know where they were putting the PE's :(
> > 
> > What's the problem? Just make a --something option that finds the
> > location of the PE using the previous BLOCK_SIZE.
> 
> But what was the previous block size ?  There's no way of knowing with the 

The one defined in the beta7 lvmtools. The old tools know that, right?
Somebody has to know if the old tools can cope with it. Then just teach
that to the new tools too when the --something is passed to pvdisplay.

> current metadata format ... and BLOCK_SIZE is only one of the variables.

Then define all them, where's the problem? Not being able to use an old
pv after the new tools and new kernel is been installed is a kind of
showstopper situation for the end user as far I can tell.  There's no
real technical reason for which we should take the the pain of this
showstopper situation IMHO, it is perfectly technically possible to
avoid that. Of course I know some more coding and testing is required to
handle that transparently, but it looks a very worthwhile effort to me.

Andrea
_______________________________________________
lvm-devel mailing list
lvm-devel@sistina.com
http://lists.sistina.com/mailman/listinfo/lvm-devel

Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Andrea Arcangeli]

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

On Wed, Aug 15, 2001 at 06:50:05PM +0200, Heinz Mauelshagen wrote:
> offset. No known way around this.

As said in the attached email (never got a reply about it yet btw)
there's definitely a way around it, there's no magic in the beta7
lvmtools, anything they can do can be done as well in the new lvmtools
if we want to (and I believe we want to). I understand you don't want to
clobber the core code with backwards compatibility cruft, but a new
backwards compatibility utility, even in a new directory to make obvious
nothing gets clobbered, could be developed and it would solve the
problem.

Andrea

[-- Attachment #2: Type: message/rfc822, Size: 4882 bytes --]

From: Andrea Arcangeli <andrea@suse.de>
To: lvm-devel@sistina.com
Subject: Re: [lvm-devel] *** Pre LVM 0.9.1 Beta 8 release test request ***
Date: Tue, 31 Jul 2001 16:35:33 +0200
Message-ID: <20010731163533.P30071@athlon.random>

On Tue, Jul 31, 2001 at 02:20:50PM +0100, Joe Thornber wrote:
> On Tue, Jul 31, 2001 at 03:13:17PM +0200, Andrea Arcangeli wrote:
> > On Tue, Jul 31, 2001 at 10:41:37AM +0100, Joe Thornber wrote:
> > > On Tue, Jul 31, 2001 at 11:25:14AM +0200, Andrea Arcangeli wrote:
> > > > then why don't you make a pvdisplay option in the new tools that allows
> > > > you to find where the PEs were positioned?
> > > 
> > > The PE location was being calculated, based on various constants such
> > > as BLOCK_SIZE (which varied through the beta series), only the
> > > currently installed tools know where they were putting the PE's :(
> > 
> > What's the problem? Just make a --something option that finds the
> > location of the PE using the previous BLOCK_SIZE.
> 
> But what was the previous block size ?  There's no way of knowing with the 

The one defined in the beta7 lvmtools. The old tools know that, right?
Somebody has to know if the old tools can cope with it. Then just teach
that to the new tools too when the --something is passed to pvdisplay.

> current metadata format ... and BLOCK_SIZE is only one of the variables.

Then define all them, where's the problem? Not being able to use an old
pv after the new tools and new kernel is been installed is a kind of
showstopper situation for the end user as far I can tell.  There's no
real technical reason for which we should take the the pain of this
showstopper situation IMHO, it is perfectly technically possible to
avoid that. Of course I know some more coding and testing is required to
handle that transparently, but it looks a very worthwhile effort to me.

Andrea
_______________________________________________
lvm-devel mailing list
lvm-devel@sistina.com
http://lists.sistina.com/mailman/listinfo/lvm-devel

[linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Kurt Garloff]

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

Hi Heinz,

thanks for your reply!

On Wed, Aug 15, 2001 at 06:50:05PM +0200, Heinz J . Mauelshagen wrote:
> On Wed, Aug 15, 2001 at 06:25:48PM +0200, Kurt Garloff wrote:
> > Is there finally a decent way to upgrade from 0.9.1b7?
> > Or is it still required to have multiple versions of the utils installed
> > just in order to be able to update from 0.9.1b7 to b8 (or 1.0)?
> 
> Well, as explained before on the lists we had an algorithm calculating
> the offset to the first PE in place till 0.9.1 Beta 7.
> 
> Therefore, we *need* to run the installed version < LVM 0.9.1 Beta 8 to
> retrieve that sector offset for all PVs and change the metadata to hold the
> offset. No known way around this.

What about adding migration code to newer LVM tools?
Make them able to get the offset to the first PE and write them to the new
place in the PV on vgscan, so the upgrade procedure is painless, because
it works automatically and tranparently. The only thing a user has to watch
is to keep kernel and userspace LVM in sync then.

I can't imagine this to be too difficult, honestly. The code is there.
You wanted to get rid of it, apparently, but why can't that be postponed?

Installing different versions of lvm tools in parallel in order to do
the upgrade inside some ramdisk of your installation system with 100% 
success sounds much more painful to me.
Left alone those people who follow a different upgrade path than the
standard one envisioned by us.

> > If yes, then I'd vote for not updating the kernel until this is fixed!
> 
> Well, we need to migrate the metadata in the future anyway once we want
> to offer support for enhanced metadata reliability and redundancy.
> We'll provide bidirectional migration tools for that then which will enable
> the user to swicth back and forth between 2 installed LVM versions.

Now, that sounds better.

> Let's keep the ball flat WRT to the migration path here.
> We've got mails with positive LVM 0.9.1 Beta 8 upgrade reports and
> no complaints TTBOMK.

Because most people just refused to upgrade given the difficulties.
Nobody wants to put his data at risk.
As it stands, I guess, SuSE will also need to refuse :-(

This is a pain, because decoupling would be bad for both sides: 
People (our customers) can't profit from your improvements and bugfixes any
longer and you'll get bug reports for old versions instead of testing of
your recent version. 

To be honest, I'd personally be disappointed if this happens:
SuSE has supported the usage of LVM and offers support for it in the
installation tool; I seriously suspect that the majority of LVM-users
is using SuSE Linux. 
Now, leaving them alone WRT upgrade is not very nice. 
You'll get decoupled from your user base.

Let's try to avoid that, please!

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, DE                                SCSI, Security

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

Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Kurt Garloff]

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

Hi Heinz,

thanks for your reply!

On Wed, Aug 15, 2001 at 06:50:05PM +0200, Heinz J . Mauelshagen wrote:
> On Wed, Aug 15, 2001 at 06:25:48PM +0200, Kurt Garloff wrote:
> > Is there finally a decent way to upgrade from 0.9.1b7?
> > Or is it still required to have multiple versions of the utils installed
> > just in order to be able to update from 0.9.1b7 to b8 (or 1.0)?
> 
> Well, as explained before on the lists we had an algorithm calculating
> the offset to the first PE in place till 0.9.1 Beta 7.
> 
> Therefore, we *need* to run the installed version < LVM 0.9.1 Beta 8 to
> retrieve that sector offset for all PVs and change the metadata to hold the
> offset. No known way around this.

What about adding migration code to newer LVM tools?
Make them able to get the offset to the first PE and write them to the new
place in the PV on vgscan, so the upgrade procedure is painless, because
it works automatically and tranparently. The only thing a user has to watch
is to keep kernel and userspace LVM in sync then.

I can't imagine this to be too difficult, honestly. The code is there.
You wanted to get rid of it, apparently, but why can't that be postponed?

Installing different versions of lvm tools in parallel in order to do
the upgrade inside some ramdisk of your installation system with 100% 
success sounds much more painful to me.
Left alone those people who follow a different upgrade path than the
standard one envisioned by us.

> > If yes, then I'd vote for not updating the kernel until this is fixed!
> 
> Well, we need to migrate the metadata in the future anyway once we want
> to offer support for enhanced metadata reliability and redundancy.
> We'll provide bidirectional migration tools for that then which will enable
> the user to swicth back and forth between 2 installed LVM versions.

Now, that sounds better.

> Let's keep the ball flat WRT to the migration path here.
> We've got mails with positive LVM 0.9.1 Beta 8 upgrade reports and
> no complaints TTBOMK.

Because most people just refused to upgrade given the difficulties.
Nobody wants to put his data at risk.
As it stands, I guess, SuSE will also need to refuse :-(

This is a pain, because decoupling would be bad for both sides: 
People (our customers) can't profit from your improvements and bugfixes any
longer and you'll get bug reports for old versions instead of testing of
your recent version. 

To be honest, I'd personally be disappointed if this happens:
SuSE has supported the usage of LVM and offers support for it in the
installation tool; I seriously suspect that the majority of LVM-users
is using SuSE Linux. 
Now, leaving them alone WRT upgrade is not very nice. 
You'll get decoupled from your user base.

Let's try to avoid that, please!

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, DE                                SCSI, Security

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

Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Eric M. Hopper]

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

On Wed, Aug 15, 2001 at 07:04:28PM +0200, Andrea Arcangeli wrote:
> On Wed, Aug 15, 2001 at 06:50:05PM +0200, Heinz Mauelshagen wrote:
> > offset. No known way around this.
> 
> As said in the attached email (never got a reply about it yet btw)
> there's definitely a way around it, there's no magic in the beta7
> lvmtools, anything they can do can be done as well in the new lvmtools
> if we want to (and I believe we want to). I understand you don't want to
> clobber the core code with backwards compatibility cruft, but a new
> backwards compatibility utility, even in a new directory to make obvious
> nothing gets clobbered, could be developed and it would solve the
> problem.

	I, frankly, won't be upgrading LVM from my 0.9 beta 7 release
until something like this exists.  The whole concept of needing some
extra special process with several steps to do the migration scares the
willies out of me.  I keep important data on my computer.  I have no
desire to lose it.

	LVM should refuse to access VGs that have PVs that have this
problem, and there should be a straighforward, single-step migration
tool that comes with the release.

-- 
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg."  --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company."  -- Mark Twain
-- Eric Hopper (hopper@omnifarious.org  http://www.omnifarious.org/~hopper) --

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

[linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Andreas Dilger]

Heinz writes:
> On Wed, Aug 15, 2001 at 06:25:48PM +0200, Kurt Garloff wrote:
> > Is there finally a decent way to upgrade from 0.9.1b7?
> > Or is it still required to have multiple versions of the utils installed
> > just in order to be able to update from 0.9.1b7 to b8 (or 1.0)?
> 
> Well, as explained before on the lists we had an algorithm calculating
> the offset to the first PE in place till 0.9.1 Beta 7.
>
> Therefore, we *need* to run the installed version < LVM 0.9.1 Beta 8 to
> retrieve that sector offset for all PVs and change the metadata to hold the
> offset. No known way around this.

Sorry, I don't get the list email anymore, despite it telling me I'm
subscribed (may be my fault, I don't know), please reply to l-k where
I know I will see it.

Saying you "need" the old versions of the installed tools to read the
on disk data is bogus, IMNSHO.  You could easily have a flag which says
"calculate the PE offsets using the old algorithm or the new algorithm".
This could easily be keyed off of the presence/absence of the new
pe_offset field in the pv_data struct on disk, and whether or not you
actually have the misaligned PEs in the first place.

When I talked to them last, the IBM EVMS folks didn't have any such
problems correctly reading either the old (possibly offset) or new
layouts with the same driver.

Also, since this bug exists only for a limited number of users (only a
subset of users who created volumes with beta 5 and beta 6), it causes
grief for anyone who is NOT affected by the bug.

> > If yes, then I'd vote for not updating the kernel until this is fixed!
> 
> Well, we need to migrate the metadata in the future anyway once we want
> to offer support for enhanced metadata reliability and redundancy.

Well, that is the future, and should not impact users of 2.4.x kernels.
Just like we found an acceptable workaround to the (incompatible) IOP 11
change (which was later reverted), it is possible to find an acceptable
workaround for the new incompatible change.  Sadly, it is no longer my
job to fix such things, and I don't have any systems here that need
fixing.

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: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Andreas Dilger]

Heinz writes:
> On Wed, Aug 15, 2001 at 06:25:48PM +0200, Kurt Garloff wrote:
> > Is there finally a decent way to upgrade from 0.9.1b7?
> > Or is it still required to have multiple versions of the utils installed
> > just in order to be able to update from 0.9.1b7 to b8 (or 1.0)?
> 
> Well, as explained before on the lists we had an algorithm calculating
> the offset to the first PE in place till 0.9.1 Beta 7.
>
> Therefore, we *need* to run the installed version < LVM 0.9.1 Beta 8 to
> retrieve that sector offset for all PVs and change the metadata to hold the
> offset. No known way around this.

Sorry, I don't get the list email anymore, despite it telling me I'm
subscribed (may be my fault, I don't know), please reply to l-k where
I know I will see it.

Saying you "need" the old versions of the installed tools to read the
on disk data is bogus, IMNSHO.  You could easily have a flag which says
"calculate the PE offsets using the old algorithm or the new algorithm".
This could easily be keyed off of the presence/absence of the new
pe_offset field in the pv_data struct on disk, and whether or not you
actually have the misaligned PEs in the first place.

When I talked to them last, the IBM EVMS folks didn't have any such
problems correctly reading either the old (possibly offset) or new
layouts with the same driver.

Also, since this bug exists only for a limited number of users (only a
subset of users who created volumes with beta 5 and beta 6), it causes
grief for anyone who is NOT affected by the bug.

> > If yes, then I'd vote for not updating the kernel until this is fixed!
> 
> Well, we need to migrate the metadata in the future anyway once we want
> to offer support for enhanced metadata reliability and redundancy.

Well, that is the future, and should not impact users of 2.4.x kernels.
Just like we found an acceptable workaround to the (incompatible) IOP 11
change (which was later reverted), it is possible to find an acceptable
workaround for the new incompatible change.  Sadly, it is no longer my
job to fix such things, and I don't have any systems here that need
fixing.

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

[linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Hubert Mantel]

Hi,

On Wed, Aug 15, Heinz Mauelshagen wrote:

> Well, as explained before on the lists we had an algorithm calculating
> the offset to the first PE in place till 0.9.1 Beta 7.
> 
> Therefore, we *need* to run the installed version < LVM 0.9.1 Beta 8 to
> retrieve that sector offset for all PVs and change the metadata to hold the
> offset. No known way around this.
          ^^^^^^^^^^^^^^^^^^^^^^^^

You are kidding, aren't you?

> Heinz    -- The LVM Guy --
                                                                  -o)
    Hubert Mantel              Goodbye, dots...                   /\\
                                                                 _\_v

Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Hubert Mantel]

Hi,

On Wed, Aug 15, Heinz Mauelshagen wrote:

> Well, as explained before on the lists we had an algorithm calculating
> the offset to the first PE in place till 0.9.1 Beta 7.
> 
> Therefore, we *need* to run the installed version < LVM 0.9.1 Beta 8 to
> retrieve that sector offset for all PVs and change the metadata to hold the
> offset. No known way around this.
          ^^^^^^^^^^^^^^^^^^^^^^^^

You are kidding, aren't you?

> Heinz    -- The LVM Guy --
                                                                  -o)
    Hubert Mantel              Goodbye, dots...                   /\\
                                                                 _\_v

Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Joe Thornber]

On Wed, Aug 15, 2001 at 07:04:28PM +0200, Andrea Arcangeli wrote:
> On Wed, Aug 15, 2001 at 06:50:05PM +0200, Heinz Mauelshagen wrote:
> > offset. No known way around this.
> 
> As said in the attached email (never got a reply about it yet btw)
> there's definitely a way around it, there's no magic in the beta7
> lvmtools, anything they can do can be done as well in the new lvmtools
> if we want to (and I believe we want to). I understand you don't want to
> clobber the core code with backwards compatibility cruft, but a new
> backwards compatibility utility, even in a new directory to make obvious
> nothing gets clobbered, could be developed and it would solve the
> problem.

I'm sorry I didn't reply to you Andrea, I didn't mean to be
disrespectful, but I didn't seem to be able to make my position
clear.  Let me try again:

In previous beta releases of LVM the PE position was always being
calculated, rather than calculated upon PV creation and put in the
metadata.  I was not aware of this.

This calculation varied through the beta series, it was based on some
constants that I changed (eg, SECTOR_SIZE which I changed to support
rawio), and constants that other people changed.  This means that
different betas have PE's at different places.

The correct solution to this (IMO) is to add the missing pe_start
field to the metadata.

From looking at the metadata I have no way of knowing which version of
software the PV was created with.  This is a sorry state of affairs,
but sadly true.  So the upgrade script does the following:

o interrogate the existing tools that created the PV to find where they put
  the PE's

o write this value into the new field.

At this point the new driver, and tools should be installed.

Should beta8 code go into the kernel ? possibly not.  I think this could cause
people a lot of trouble if they are not familiar with the issues.

Should we have made the change ? yes.  If you *do* care you can choose
to upgrade.

- Joe

Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Joe Thornber]

On Wed, Aug 15, 2001 at 07:04:28PM +0200, Andrea Arcangeli wrote:
> On Wed, Aug 15, 2001 at 06:50:05PM +0200, Heinz Mauelshagen wrote:
> > offset. No known way around this.
> 
> As said in the attached email (never got a reply about it yet btw)
> there's definitely a way around it, there's no magic in the beta7
> lvmtools, anything they can do can be done as well in the new lvmtools
> if we want to (and I believe we want to). I understand you don't want to
> clobber the core code with backwards compatibility cruft, but a new
> backwards compatibility utility, even in a new directory to make obvious
> nothing gets clobbered, could be developed and it would solve the
> problem.

I'm sorry I didn't reply to you Andrea, I didn't mean to be
disrespectful, but I didn't seem to be able to make my position
clear.  Let me try again:

In previous beta releases of LVM the PE position was always being
calculated, rather than calculated upon PV creation and put in the
metadata.  I was not aware of this.

This calculation varied through the beta series, it was based on some
constants that I changed (eg, SECTOR_SIZE which I changed to support
rawio), and constants that other people changed.  This means that
different betas have PE's at different places.

The correct solution to this (IMO) is to add the missing pe_start
field to the metadata.

>From looking at the metadata I have no way of knowing which version of
software the PV was created with.  This is a sorry state of affairs,
but sadly true.  So the upgrade script does the following:

o interrogate the existing tools that created the PV to find where they put
  the PE's

o write this value into the new field.

At this point the new driver, and tools should be installed.

Should beta8 code go into the kernel ? possibly not.  I think this could cause
people a lot of trouble if they are not familiar with the issues.

Should we have made the change ? yes.  If you *do* care you can choose
to upgrade.

- Joe

Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Joe Thornber]

Andreas,

On Wed, Aug 15, 2001 at 11:55:48AM -0600, Andreas Dilger wrote:
> Sorry, I don't get the list email anymore, despite it telling me I'm
> subscribed (may be my fault, I don't know), please reply to l-k where
> I know I will see it.

Your mail is broken, I have tried to mail you many times over the last
few weeks from different email addresses and different ISP's.  Other
people have been trying too.  Did you notice a time when it suddenly
went quiet ?

> Saying you "need" the old versions of the installed tools to read the
> on disk data is bogus, IMNSHO.  You could easily have a flag which says
> "calculate the PE offsets using the old algorithm or the new algorithm".
> This could easily be keyed off of the presence/absence of the new
> pe_offset field in the pv_data struct on disk, and whether or not you
> actually have the misaligned PEs in the first place.

That assumes you have just two alternatives, this is not the case.

> When I talked to them last, the IBM EVMS folks didn't have any such
> problems correctly reading either the old (possibly offset) or new
> layouts with the same driver.

Then they don't understand the problem, though hopefully by the time they
release people will have migrated to the new format.

- Joe

Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Andrea Arcangeli]

On Wed, Aug 15, 2001 at 09:06:22PM +0100, Joe Thornber wrote:
> In previous beta releases of LVM the PE position was always being
> calculated, rather than calculated upon PV creation and put in the
> metadata.  I was not aware of this.
> 
> This calculation varied through the beta series, it was based on some
> constants that I changed (eg, SECTOR_SIZE which I changed to support

You can put the algorithm used by beta7 in a separate program and ask
this program where the pe start. Since the beta7 tools knows where the
pe_start (the proof is that I can use lvm in my machines), also this new
program will know where the pe_start.

Andrea

Re: [lvm-devel] Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Christoph Hellwig]

On Wed, Aug 15, 2001 at 10:16:23PM +0200, Andrea Arcangeli wrote:
> You can put the algorithm used by beta7 in a separate program and ask
> this program where the pe start. Since the beta7 tools knows where the
> pe_start (the proof is that I can use lvm in my machines), also this new
> program will know where the pe_start.

In principle yes, but beta7 is the wrong target, the one that needs to
be converted easily is the old (=0.9) format, people using betas should
really know what they are doing while a seamless upgrade from the latest
release version is a must.

	Christoph

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

Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Eric M. Hopper]

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

On Wed, Aug 15, 2001 at 09:06:22PM +0100, Joe Thornber wrote:
> 
> From looking at the metadata I have no way of knowing which version of
> software the PV was created with.  This is a sorry state of affairs,
> but sadly true.  So the upgrade script does the following:
> 
> o interrogate the existing tools that created the PV to find where they put
>   the PE's
> 
> o write this value into the new field.
> 
> At this point the new driver, and tools should be installed.

	So, has the metadata also been updated to have a version number
field in an easily found location?  This is a very unpleasant state of
affairs, and it will happen again if you haven't done this.

	This helps my peace of mind about doing the upgrade.  Perhaps
now I will do it with confidence that it will work and I'll get the
order of operations right.

	One question I have:

	Does it hurt for the old drivers to be in the kernel at the time
you run the upgrade script if none of the VGs are 'active'?

	I compiled LVM into my kernel instead of leaving it as a module,
so if it were a problem, I'd have to compile a new kernel that didn't
have the drivers.

Have fun (if at all possible),
-- 
"It does me no injury for my neighbor to say there are twenty gods or no God.
It neither picks my pocket nor breaks my leg."  --- Thomas Jefferson
"Go to Heaven for the climate, Hell for the company."  -- Mark Twain
-- Eric Hopper (hopper@omnifarious.org  http://www.omnifarious.org/~hopper) --

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

[linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Andrea Arcangeli]

On Wed, Aug 15, 2001 at 11:55:48AM -0600, Andreas Dilger wrote:
> Saying you "need" the old versions of the installed tools to read the
> on disk data is bogus, IMNSHO.  You could easily have a flag which says
> "calculate the PE offsets using the old algorithm or the new algorithm".

Definitely. This is what I was asking for. That would be optimal.

> Also, since this bug exists only for a limited number of users (only a
> subset of users who created volumes with beta 5 and beta 6), it causes
> grief for anyone who is NOT affected by the bug.

Agreed. I understand that here I am biased but I don't care much about
that possible misalignment too because we never shipped a beta[56].

> Well, that is the future, and should not impact users of 2.4.x kernels.
> Just like we found an acceptable workaround to the (incompatible) IOP 11
> change (which was later reverted), it is possible to find an acceptable
> workaround for the new incompatible change.  Sadly, it is no longer my

Agreed.

Andrea

Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Andrea Arcangeli]

On Wed, Aug 15, 2001 at 11:55:48AM -0600, Andreas Dilger wrote:
> Saying you "need" the old versions of the installed tools to read the
> on disk data is bogus, IMNSHO.  You could easily have a flag which says
> "calculate the PE offsets using the old algorithm or the new algorithm".

Definitely. This is what I was asking for. That would be optimal.

> Also, since this bug exists only for a limited number of users (only a
> subset of users who created volumes with beta 5 and beta 6), it causes
> grief for anyone who is NOT affected by the bug.

Agreed. I understand that here I am biased but I don't care much about
that possible misalignment too because we never shipped a beta[56].

> Well, that is the future, and should not impact users of 2.4.x kernels.
> Just like we found an acceptable workaround to the (incompatible) IOP 11
> change (which was later reverted), it is possible to find an acceptable
> workaround for the new incompatible change.  Sadly, it is no longer my

Agreed.

Andrea

Re: [lvm-devel] Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Andrea Arcangeli]

On Wed, Aug 15, 2001 at 10:20:30PM +0200, Christoph Hellwig wrote:
> In principle yes, but beta7 is the wrong target, the one that needs to
> be converted easily is the old (=0.9) format, people using betas should
> really know what they are doing while a seamless upgrade from the latest
> release version is a must.

fine with me, beta7 or 0.9 doesn't matter in this respect.

Andrea

Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Joe Thornber]

On Wed, Aug 15, 2001 at 03:24:32PM -0500, Eric M. Hopper wrote:
> On Wed, Aug 15, 2001 at 09:06:22PM +0100, Joe Thornber wrote:
> > 
> > From looking at the metadata I have no way of knowing which version of
> > software the PV was created with.  This is a sorry state of affairs,
> > but sadly true.  So the upgrade script does the following:
> > 
> > o interrogate the existing tools that created the PV to find where they put
> >   the PE's
> > 
> > o write this value into the new field.
> > 
> > At this point the new driver, and tools should be installed.
> 
> 	So, has the metadata also been updated to have a version number
> field in an easily found location?  This is a very unpleasant state of
> affairs, and it will happen again if you haven't done this.

The metadata has always had a version number field.  This is a single
integer field rather than a major/minor/patchlevel triplet which I
would prefer.  This field used to be set to 1, and is now set to two
since the extra field was added.  The real problem was that the
metadata format wasn't self consistent, it didn't tell you everything
you needed to know, there was 'magic' in the tools.

> 	This helps my peace of mind about doing the upgrade.  Perhaps
> now I will do it with confidence that it will work and I'll get the
> order of operations right.

Read the instructions and follow the steps carefully and you should
have no trouble.

> 
> 	One question I have:
> 
> 	Does it hurt for the old drivers to be in the kernel at the time
> you run the upgrade script if none of the VGs are 'active'?

Let's see ... I think the old drivers do need to be present, so if
necessary a dummy LV can be created on empty PV's in order to get
pvdisplay to show the location of the start PE.  Yes.

> 	I compiled LVM into my kernel instead of leaving it as a module,
> so if it were a problem, I'd have to compile a new kernel that didn't
> have the drivers.

If I were you I'd have builds of both the old and new kernel/tools
ready before you start.  

- Joe

Re: [linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Joe Thornber]

On Wed, Aug 15, 2001 at 11:13:30PM +0200, Andrea Arcangeli wrote:
> On Wed, Aug 15, 2001 at 11:55:48AM -0600, Andreas Dilger wrote:
> > Saying you "need" the old versions of the installed tools to read the
> > on disk data is bogus, IMNSHO.  You could easily have a flag which says
> > "calculate the PE offsets using the old algorithm or the new algorithm".
> 
> Definitely. This is what I was asking for. That would be optimal.

I'm going to go through all the beta releases and confirm this, but as
I understand it there are not just two ways of calculating it.
Otherwise yes it would be easy.

- Joe

[linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Heinz J . Mauelshagen]

Kurt,

I just picked your e-mail standing for a couple to summarize:

- some people report, that the bi-directional upgrade path from
  <= LVM 0.9.1 Beta 7 to LVM 0.9.1 Beta 8 and beyond is fine
- some people complain that there could be an easier solution
  and that there are just 2 cases to distinguish which could easily be covered
  by a better upgrade tool which is *not* true

As Joe stated easily and I tried to explain briefly a while ago:
there's multiple cases and the solution we have right now seemed to be the
cleanest approach to cover them all *without* hitting the trape of missing some!

Because we take your complaints seriously we are investigating, if there's a
well defined finite amount of cases that we actually can cover with a simple
tool. 

If so, you are going get it ;-)

Please stay tuned and give as some time...

We'll keep you posted.

Thanks for your understanding!

Regards,
Heinz    -- The LVM Guy --


 
On Wed, Aug 15, 2001@07:19:12PM +0200, Kurt Garloff wrote:
> Hi Heinz,
> 
> thanks for your reply!
> 
> On Wed, Aug 15, 2001 at 06:50:05PM +0200, Heinz J . Mauelshagen wrote:
> > On Wed, Aug 15, 2001 at 06:25:48PM +0200, Kurt Garloff wrote:
> > > Is there finally a decent way to upgrade from 0.9.1b7?
> > > Or is it still required to have multiple versions of the utils installed
> > > just in order to be able to update from 0.9.1b7 to b8 (or 1.0)?
> > 
> > Well, as explained before on the lists we had an algorithm calculating
> > the offset to the first PE in place till 0.9.1 Beta 7.
> > 
> > Therefore, we *need* to run the installed version < LVM 0.9.1 Beta 8 to
> > retrieve that sector offset for all PVs and change the metadata to hold the
> > offset. No known way around this.
> 
> What about adding migration code to newer LVM tools?
> Make them able to get the offset to the first PE and write them to the new
> place in the PV on vgscan, so the upgrade procedure is painless, because
> it works automatically and tranparently. The only thing a user has to watch
> is to keep kernel and userspace LVM in sync then.
> 
> I can't imagine this to be too difficult, honestly. The code is there.
> You wanted to get rid of it, apparently, but why can't that be postponed?
> 
> Installing different versions of lvm tools in parallel in order to do
> the upgrade inside some ramdisk of your installation system with 100% 
> success sounds much more painful to me.
> Left alone those people who follow a different upgrade path than the
> standard one envisioned by us.
> 
> > > If yes, then I'd vote for not updating the kernel until this is fixed!
> > 
> > Well, we need to migrate the metadata in the future anyway once we want
> > to offer support for enhanced metadata reliability and redundancy.
> > We'll provide bidirectional migration tools for that then which will enable
> > the user to swicth back and forth between 2 installed LVM versions.
> 
> Now, that sounds better.
> 
> > Let's keep the ball flat WRT to the migration path here.
> > We've got mails with positive LVM 0.9.1 Beta 8 upgrade reports and
> > no complaints TTBOMK.
> 
> Because most people just refused to upgrade given the difficulties.
> Nobody wants to put his data at risk.
> As it stands, I guess, SuSE will also need to refuse :-(
> 
> This is a pain, because decoupling would be bad for both sides: 
> People (our customers) can't profit from your improvements and bugfixes any
> longer and you'll get bug reports for old versions instead of testing of
> your recent version. 
> 
> To be honest, I'd personally be disappointed if this happens:
> SuSE has supported the usage of LVM and offers support for it in the
> installation tool; I seriously suspect that the majority of LVM-users
> is using SuSE Linux. 
> Now, leaving them alone WRT upgrade is not very nice. 
> You'll get decoupled from your user base.
> 
> Let's try to avoid that, please!
> 
> Regards,
> -- 
> Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
> GPG key: See mail header, key servers         Linux kernel development
> SuSE GmbH, Nuernberg, DE                                SCSI, Security

*** 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
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Kurt Garloff]

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

Hi Heinz,

thanks for your answer!

On Fri, Aug 17, 2001 at 11:16:36AM +0200, Heinz J . Mauelshagen wrote:
> I just picked your e-mail standing for a couple to summarize:
> 
> - some people report, that the bi-directional upgrade path from
>   <= LVM 0.9.1 Beta 7 to LVM 0.9.1 Beta 8 and beyond is fine

For individuals that are doing their installations manually, the approach
offered by you is no serious obstacle, I think.

The problem is those relying on the distributor to handle such things and
those are the vast majority of people. And, indeed, it's the distributor's
job to handle the complexity involved in things as LVM.

Now, we have to offer a fail proof upgrade from all our deployed LVM
versions for the customers. If we can't do it, we can't do the update,
because customers just won't accept it.

Ideally, we would not need to worry, as new lvm utils and the new lvm code
in kernel would handle old formats as well. 
For an important piece of software that is used by a large user base, that
would be an absolute requirement.

Now, I know that the world is not ideal, and people make mistakes.

Look at Berkeley db and guess why people more and more refrain from using it.
reiserfs had a similar problems with on-disk format changes in the past and
we really had to work hard with the reiser people to get it fixed. But it
happened and we could continue recommending reiserfs, as it could be used
without major pains.

I'm very unhappy to see that LVM has similar problems. On disk format
changes should normally not be required, as you should use an extendable
format that does only get new, added fields, which aren't required by old
versions. New versions would either fill them in automatically or be able to
do without them,@least for a few revisions.

To give an example: reiserfs 3.6.x code (in kernel 2.4) can read and write
the 3.5 on-disk format (in 2.2 SuSE kernels) without problems, so you can go
forward and backward between 2.2 and 2.4 kernels without problems.
If you need the new 3.6 features, you can convert by simply using a
mount parameter and only then there's no way back.
This is an ideal way of dealing with updating file/on-disk formats.

I hope you agree that this would be the desirable way to go.

People need to be confident that using a technology, such as reiser (or
LVM), does not give them headaches in the future, because they can't
upgrade any more.

So far for our concerns. I hope they are very clear now.

Now, for some reasons, things are not so ideal.
So we need to try to keep the damage as small as possible.

> - some people complain that there could be an easier solution
>   and that there are just 2 cases to distinguish which could easily be covered
>   by a better upgrade tool which is *not* true
> 
> As Joe stated easily and I tried to explain briefly a while ago:
> there's multiple cases and the solution we have right now seemed to be the
> cleanest approach to cover them all *without* hitting the trape of missing 
> some!

Did I correctly understand him that there's no straight-forward way to
determine the LVM on-disk version? Hard to believe ...
You know what the next field to be added should be IMHO then, I guess?
(In all of the file formats I've been designing recently, I put a magic
 number to recognize the format plus a version number right at the
 beginning.)

Now, we (SuSE) were using beta versions of LVM, as we wanted to push LVM
development and testing on the one hand and wanted to provide the features
for our users on the other hand.
I would have assumed that this has been discussed with you before?
If not, it was not such a good idea to use the beta versions.
Maybe things also went wrong there :-(
Hopefully this can be improved for the future then.

> Because we take your complaints seriously we are investigating, if there's a
> well defined finite amount of cases that we actually can cover with a simple
> tool. 

As far as I can see, there's 0.8, 0.9, 0.9.1b4 and 0.9.1b7 in widespread use
out in the wild.
Ideally, we could handle all of them easily. Less ideally, only a subset of
them ...

> If so, you are going get it ;-)
> 
> Please stay tuned and give as some time...

Now, this sound very good. I'd be very happy if we find a solution which
lets those people not alone that used older LVM versions relying on the
distribution support.

I would offer you help with working on it, but as I personally do not have
resources to do programming on LVM tools, I can't promise anything. But I'm
optimistic some colleagues will also want to help if necessary.
What we can and will do is testing.

> We'll keep you posted.
> 
> Thanks for your understanding!

Thanks for addressing our concerns!

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
Physics: Plasma simulations  <K.Garloff@Phys.TUE.NL>  [TU Eindhoven, NL]
Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
 (See mail header or public key servers for PGP2 and GPG public keys.)

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

[linux-lvm] Re: *** ANNOUNCEMENT *** LVM 1.0 available at www.sistina.com

[Heinz J . Mauelshagen]

On Fri, Aug 17, 2001 at 12:23:26PM +0200, Kurt Garloff wrote:
> Hi Heinz,
> 
> thanks for your answer!
> 
> On Fri, Aug 17, 2001 at 11:16:36AM +0200, Heinz J . Mauelshagen wrote:
> > I just picked your e-mail standing for a couple to summarize:
> > 
> > - some people report, that the bi-directional upgrade path from
> >   <= LVM 0.9.1 Beta 7 to LVM 0.9.1 Beta 8 and beyond is fine
> 
> For individuals that are doing their installations manually, the approach
> offered by you is no serious obstacle, I think.
> 
> The problem is those relying on the distributor to handle such things and
> those are the vast majority of people. And, indeed, it's the distributor's
> job to handle the complexity involved in things as LVM.
> 
> Now, we have to offer a fail proof upgrade from all our deployed LVM
> versions for the customers. If we can't do it, we can't do the update,
> because customers just won't accept it.
> 
> Ideally, we would not need to worry, as new lvm utils and the new lvm code
> in kernel would handle old formats as well. 
> For an important piece of software that is used by a large user base, that
> would be an absolute requirement.
> 
> Now, I know that the world is not ideal, and people make mistakes.
> 
> Look at Berkeley db and guess why people more and more refrain from using it.
> reiserfs had a similar problems with on-disk format changes in the past and
> we really had to work hard with the reiser people to get it fixed. But it
> happened and we could continue recommending reiserfs, as it could be used
> without major pains.
> 
> I'm very unhappy to see that LVM has similar problems. On disk format
> changes should normally not be required, as you should use an extendable
> format that does only get new, added fields, which aren't required by old
> versions.

Exactly that's what we did.
One additional field in the PV structure.

> New versions would either fill them in automatically or be able to
> do without them, at least for a few revisions.

That 'automatically' is exactly the core of the problem.
We didn't have a solution so far but have a new idea and are
(as mentioned in my previous mail) working on one now...

Give us some time, please.

BTW: there have been a couple of user transparent automatic metadata upgrades
     already but this is the first one causing a headache ;-)

> 
> To give an example: reiserfs 3.6.x code (in kernel 2.4) can read and write
> the 3.5 on-disk format (in 2.2 SuSE kernels) without problems, so you can go
> forward and backward between 2.2 and 2.4 kernels without problems.
> If you need the new 3.6 features, you can convert by simply using a
> mount parameter and only then there's no way back.
> This is an ideal way of dealing with updating file/on-disk formats.
> 
> I hope you agree that this would be the desirable way to go.

Yes,
actually that's one major design goal in future LVM versions (I call
it virtual data layer) to address future major metadata changes wich aim
to offer enhanced reliability and redundancy.

> 
> People need to be confident that using a technology, such as reiser (or
> LVM), does not give them headaches in the future, because they can't
> upgrade any more.
> 
> So far for our concerns. I hope they are very clear now.

Yes, as mentioned before: we take those concerns seriously.
There's no bad intention or something behind *not* deploying it in the
first place.

We just weren't genious enough to find the possible solution we
hopefully have now ;-)

Regards,
Heinz    -- The LVM Guy --


> 
> Now, for some reasons, things are not so ideal.
> So we need to try to keep the damage as small as possible.
> 
> > - some people complain that there could be an easier solution
> >   and that there are just 2 cases to distinguish which could easily be covered
> >   by a better upgrade tool which is *not* true
> > 
> > As Joe stated easily and I tried to explain briefly a while ago:
> > there's multiple cases and the solution we have right now seemed to be the
> > cleanest approach to cover them all *without* hitting the trape of missing 
> > some!
> 
> Did I correctly understand him that there's no straight-forward way to
> determine the LVM on-disk version? Hard to believe ...
> You know what the next field to be added should be IMHO then, I guess?
> (In all of the file formats I've been designing recently, I put a magic
>  number to recognize the format plus a version number right at the
>  beginning.)
> 
> Now, we (SuSE) were using beta versions of LVM, as we wanted to push LVM
> development and testing on the one hand and wanted to provide the features
> for our users on the other hand.
> I would have assumed that this has been discussed with you before?
> If not, it was not such a good idea to use the beta versions.
> Maybe things also went wrong there :-(
> Hopefully this can be improved for the future then.
> 
> > Because we take your complaints seriously we are investigating, if there's a
> > well defined finite amount of cases that we actually can cover with a simple
> > tool. 
> 
> As far as I can see, there's 0.8, 0.9, 0.9.1b4 and 0.9.1b7 in widespread use
> out in the wild.
> Ideally, we could handle all of them easily. Less ideally, only a subset of
> them ...
> 
> > If so, you are going get it ;-)
> > 
> > Please stay tuned and give as some time...
> 
> Now, this sound very good. I'd be very happy if we find a solution which
> lets those people not alone that used older LVM versions relying on the
> distribution support.
> 
> I would offer you help with working on it, but as I personally do not have
> resources to do programming on LVM tools, I can't promise anything. But I'm
> optimistic some colleagues will also want to help if necessary.
> What we can and will do is testing.
> 
> > We'll keep you posted.
> > 
> > Thanks for your understanding!
> 
> Thanks for addressing our concerns!
> 
> Regards,
> -- 
> Kurt Garloff                   <kurt@garloff.de>         [Eindhoven, NL]
> Physics: Plasma simulations  <K.Garloff@Phys.TUE.NL>  [TU Eindhoven, NL]
> Linux: SCSI, Security          <garloff@suse.de>    [SuSE Nuernberg, DE]
>  (See mail header or public key servers for PGP2 and GPG public keys.)

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

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