From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 22:04:27 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 172801065672; Thu, 28 Jun 2012 22:04:27 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 65B248FC15; Thu, 28 Jun 2012 22:04:26 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 184412842A; Fri, 29 Jun 2012 00:04:19 +0200 (CEST) Received: from [192.168.1.2] (static-84-242-120-26.net.upcbroadband.cz [84.242.120.26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id CBA2B28427; Fri, 29 Jun 2012 00:04:17 +0200 (CEST) Message-ID: <4FECD4E1.1070505@quip.cz> Date: Fri, 29 Jun 2012 00:04:17 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628172526.GA1438@garage.freebsd.pl> In-Reply-To: <20120628172526.GA1438@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Jun 2012 22:50:50 +0000 Cc: Doug Rabson , Marcel Moolenaar , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 22:04:27 -0000 Pawel Jakub Dawidek wrote: > On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: >> >> On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: >>> >>> All of the above is ugly, U'm afraid :( >> >> Indeed. The only sane way is to put the metadata in a partition of its own. >> Every compliant OS will respect that and consequently will not scribble over >> the data unintentionally. Any other scheme that puts valuable data in some >> undocumented or unregistered location is violating the GPT spec right away >> and is susceptible to being clobbered unintentionally. > > If the user runs: > > # gpart create -s GPT /dev/mirror/foo > > for me it is obvious that he wants to partition the mirror device and > not individual disks. Because the mirror was configured earlier, do you > expect gmirror to somehow detect that someone is writting GPT metadata > later and magically place GPT metadata on the raw disk and move mirror's > metadata to some magic partition? Not to mention that the mirror itself > doesn't have to be configured on top of raw disks. And not to mention > that the mirror may never be partitioned. > > If GPT in your opinion is limited only to raw disks then I guess the > best way to fix that is to refuse to configure GPT on anything except > raw disks (which was already proposed by Andrey?). In my opinion this is > unacceptable, but I think this is what you are suggesting. > > One of the GEOM design goals was to be flexible. Let the user decide in > what order he wants to configure various layers. How do you know that in > every possible scenerio software mirroring should come after > partitioning and encryption after mirroring? Why can't we provide > flexible tools to the user and let him decide? Maybe GPT nesting > violates standards, but why can't we support it as an extention, really? > > I recognize the need to warn users if they use FreeBSD-specific > features. We do that with non-standard APIs. So how about this. > > Let's modify gpart(8) to print a warning if GPT is configured on > something else than raw disk. Let's the warning say that such > configuration is non-standard and problems are expected if the disk is > shared between other OSes. > > In my opinion that's fair. > > With such a warning in place, I think we can allow users to decide on > their own if they really want that or not. Then, we can also improve > FreeBSD boot loader to play nice with FreeBSD-specific extensions. I think this is valid point of view. FreeBSD already does things not supported by other OSes and I am completely fine with it - I am running FreeBSD on servers, not sharing anything with other OSes so I prefer extended FreeBSD specific features over 100% standard compliant behaviour crippling SW mirroring etc. I think that our tools should support / provide all standard compliant (compatible) features, but let user to choose any other extended non-compatible features if user wants it. Even if it can be seen as foot shooting by somebody else. And maybe one day our solution will be widespread and taken as a standard. Miroslav Lachman