Re: geom_mirror silently upgrading metadata [Was: cvs commit: src UPDATING]

From: Pawel Jakub Dawidek <pjd_at_FreeBSD.org>
Date: Fri, 18 Jul 2008 09:06:24 +0200
On Tue, Jul 15, 2008 at 07:51:39PM +1000, Peter Jeremy wrote:
> On 2008-Jul-15 02:14:46 -0700, Maxim Sobolev <sobomax_at_freebsd.org> wrote:
> >Not really relevant to the change in question, but I think that the 
> >whole idea of geom_mirror updating on-disk metadata automagically is not 
> >  very well thought out. For example one could try booting 7.x kernel on 
> >6.x system just to see how well it goes with the intention to revert 
> >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 
> >this issue today, with the target machine stuck in unbootable state on 
> >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 
> >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).

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.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd_at_FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

Received on Fri Jul 18 2008 - 07:50:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:33 UTC