Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Jul 2008 19:51:39 +1000
From:      Peter Jeremy <peterjeremy@optushome.com.au>
To:        Maxim Sobolev <sobomax@freebsd.org>
Cc:        Remko Lodder <remko@freebsd.org>, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, "current@freebsd.org" <current@freebsd.org>
Subject:   Re: geom_mirror silently upgrading metadata [Was: cvs commit: src UPDATING]
Message-ID:  <20080715095139.GA62764@server.vk2pj.dyndns.org>
In-Reply-To: <487C6A86.20508@FreeBSD.org>
References:  <200807131153.m6DBrDkX067657@repoman.freebsd.org> <487C6A86.20508@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--VZEZlOQeSr/zV9d3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.

Agreed.  I raised the same issue on -stable in late June.

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

I was lucky that I didn't need to revert.

>IMHO metadata update should be performed if and only if explicitly=20
>requested by the administrator.

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).

--=20
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.

--VZEZlOQeSr/zV9d3
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkh8cysACgkQ/opHv/APuId+jgCeMXoS9EoKz9RPzsILimbAJgEo
MO0AoJHoei1lQNh9dS8SDx/RkuOdRtIq
=5MlO
-----END PGP SIGNATURE-----

--VZEZlOQeSr/zV9d3--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080715095139.GA62764>