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
This archive was generated by hypermail 2b29 : Wed Aug 15 2001 - 21:00:59 EST