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

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

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

[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

[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

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

[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: [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: *** 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

[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: [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: *** 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

[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