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

[Todd M. Roy]

>From reading the README.1st file, is my understanding
correct that if  one  already has migrated from
lvm 0.9.1b7 to 0.9.1b8, it is
*NOT* necessary to run pvvversion again?

Thanks,

  Todd
**********************************************************************
This footnote confirms that this email message has been swept by 
MIMEsweeper for the presence of computer viruses.
**********************************************************************

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

[AJ Lewis]

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

On Wed, Aug 15, 2001 at 02:35:03PM -0400, Todd M. Roy wrote:
> >From reading the README.1st file, is my understanding
> correct that if  one  already has migrated from
> lvm 0.9.1b7 to 0.9.1b8, it is
> *NOT* necessary to run pvvversion again?

That is correct.

-- 
AJ Lewis
Sistina Software Inc.                  Voice:  612-638-0500
1313 5th St SE, Suite 111              Fax:    612-638-0500
Minneapolis, MN 55414                  E-Mail: lewis@sistina.com
http://www.sistina.com

Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B  52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
 (Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)

-----Begin Obligatory Humorous Quote----------------------------------------
"We succeed because our competitors are idiots" - anonymous
-----End Obligatory Humorous Quote------------------------------------------

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

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