Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Nov 2008 11:47:41 +0000 (UTC)
From:      Vadim Goncharov <vadim_nuclight@mail.ru>
To:        freebsd-current@freebsd.org
Subject:   Re: geom_mirror silently upgrading metadata [Was: cvs commit: src UPDATING]
Message-ID:  <slrnghis6s.163f.vadim_nuclight@server.filona.x88.info>
References:  <200807131153.m6DBrDkX067657@repoman.freebsd.org> <487C6A86.20508@FreeBSD.org> <20080715095139.GA62764@server.vk2pj.dyndns.org> <20080718070624.GC1976@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Pawel Jakub Dawidek! 

On Fri, 18 Jul 2008 09:06:24 +0200; Pawel Jakub Dawidek wrote about 'Re: geom_mirror silently upgrading metadata [Was: cvs commit: src UPDATING]':


>> Agreed.  It's especially worrying that there's absolutely no warning
>> that a particular version of geom_mirror has a different metadata
>> format and loading it will make your gmirror unusable with an older
>> gmirror.  IMHO, any geom changes changes that prevent reversion
>> should be noted in UPDATING (at the very least).

> Just to be clear. I fully agree with you guys. What I could do about
> that when I was working on gmirror (starting from the simplest
> solution):

> 1. Skip disks which have version lower then what we have in the kernel.

> 2. Upgrade the on-disk metadata automatically.

> 3. Make gmirror kernel module to work with all the previous versions and
>    add 'gmirror upgrade' command, so one can upgrade on-disk metadata.

> Keep in mind that unlike gconcat/gstripe, gmirror (or graid3) metadata
> is updated all the time to keep track of what's going on, so to be able
> to support older versions I've to have also conversion from the most
> recent version to the older ones, which may not be always
> straight-forward.

> Of course the only right solution is the 3rd one, but it is also the
> least trivial to implement. I implemented the 2nd one as a "good enough"
> alternative. Don't get me wrong, it's not super-hard to implement, so if
> there is a volunteer willing to code it, I can provide guidelines, if
> there isn't one, I'll get back to it, but be sure there is a PR assigned
> to me.

There are solution 2.5 - ask at boot for upgrade, if answer was negative (or
timeout fired for case of remote upgrade), then start the mirror read-only,
with the possibility to later give 'upgrade' command, switching to normal
operation.

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnghis6s.163f.vadim_nuclight>