From owner-freebsd-current@FreeBSD.ORG Tue Jul 15 09:14:59 2008 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A2421065676; Tue, 15 Jul 2008 09:14:59 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id D07338FC1E; Tue, 15 Jul 2008 09:14:58 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.40] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id m6F9EuX7054884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Jul 2008 02:14:57 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <487C6A86.20508@FreeBSD.org> Date: Tue, 15 Jul 2008 02:14:46 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Remko Lodder References: <200807131153.m6DBrDkX067657@repoman.freebsd.org> In-Reply-To: <200807131153.m6DBrDkX067657@repoman.freebsd.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@FreeBSD.org, Pawel Jakub Dawidek , "current@freebsd.org" Subject: geom_mirror silently upgrading metadata [Was: cvs commit: src UPDATING] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2008 09:14:59 -0000 Remko Lodder wrote: > MFC r180345 > > Add missing information for geom_mirror metadata. > > PR: 124434 > Submitted by: Philip M. Golluci > MFC after: 3 days 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. We have excellent tool called nextboot (8) that really helps doing it safely or semi-safely even remotely over ssh. In the worst case you just need to cycle the power to return to the previous configuration. Automatic conversion makes it impossible to go back without some heavy manual intervention at console necessary to boot off the disk directly 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. Another possible common scenarios where automatic updates can do harm are: booting 7.0 recovery CD on 6.x system or multi-boot system with several FreeBSD versions installed on the same machine and sharing mirrored disk(s). IMHO metadata update should be performed if and only if explicitly requested by the administrator. In all other cases the driver should do conversion from old format to the new one in memory when reading metadata and convert back when saving it. Printing big warning about the need to update metadata mentioning the fact that using mirror with old kernels won't be possible afterwards is OK, though. At least this has to be done for the cases when the difference is reasonable, such as just one generation in my case. If the difference is beyond any reasonable limits (i.e. v3 on-disk metadata and v6 module), the driver should present console prompt and let admin make a decision explicitly. -Maxim