Date: Fri, 18 Jul 2008 09:06:24 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: Remko Lodder <remko@freebsd.org>, src-committers@freebsd.org, "current@freebsd.org" <current@freebsd.org> Subject: Re: geom_mirror silently upgrading metadata [Was: cvs commit: src UPDATING] Message-ID: <20080718070624.GC1976@garage.freebsd.pl> In-Reply-To: <20080715095139.GA62764@server.vk2pj.dyndns.org> References: <200807131153.m6DBrDkX067657@repoman.freebsd.org> <487C6A86.20508@FreeBSD.org> <20080715095139.GA62764@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ghzN8eJ9Qlbqn3iT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 15, 2008 at 07:51:39PM +1000, Peter Jeremy wrote: > On 2008-Jul-15 02:14:46 -0700, Maxim Sobolev <sobomax@freebsd.org> wrote: > >Not really relevant to the change in question, but I think that the=20 > >whole idea of geom_mirror updating on-disk metadata automagically is not= =20 > > very well thought out. For example one could try booting 7.x kernel on= =20 > >6.x system just to see how well it goes with the intention to revert=20 > >back if it doesn't work out well. >=20 > Agreed. I raised the same issue on -stable in late June. >=20 > >and re-creating/re-syncing the mirror after that. I've run into exactly= =20 > >this issue today, with the target machine stuck in unbootable state on= =20 > >another continent many thousand miles away. >=20 > I was lucky that I didn't need to revert. >=20 > >IMHO metadata update should be performed if and only if explicitly=20 > >requested by the administrator. >=20 > 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. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --ghzN8eJ9Qlbqn3iT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFIgEDwForvXbEpPzQRAtFaAJ0ctgnwHqRsVRB/2hR5MDfbgN3KHwCgoBPU 4UKioV8Bg9ndmRCfzX5g2As= =Oaym -----END PGP SIGNATURE----- --ghzN8eJ9Qlbqn3iT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080718070624.GC1976>