From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 10:10:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E97D1065688 for ; Thu, 28 Jun 2012 10:10:16 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm4.bullet.mail.ird.yahoo.com (nm4.bullet.mail.ird.yahoo.com [77.238.189.61]) by mx1.freebsd.org (Postfix) with SMTP id B74518FC17 for ; Thu, 28 Jun 2012 10:10:15 +0000 (UTC) Received: from [77.238.189.234] by nm4.bullet.mail.ird.yahoo.com with NNFMP; 28 Jun 2012 10:10:13 -0000 Received: from [217.146.188.173] by tm15.bullet.mail.ird.yahoo.com with NNFMP; 28 Jun 2012 10:10:13 -0000 Received: from [127.0.0.1] by smtp141.mail.ird.yahoo.com with NNFMP; 28 Jun 2012 10:10:13 -0000 X-Yahoo-Newman-Id: 327864.28753.bm@smtp141.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4VkEvKYVM1kOK6KImTgspsbRlNNbHUI2PaO5OfXrk9CgX8S ZJaazTcRTQIBdQI3qrFpiQfr.nPWAVz80EfdgTvW_dRRyyXpmFJ7_ErmNn84 SoJvut9yOOt.qHHZqcWKs4tEtCyj5.d_BDyJVjtHIC4iGVio1t.UmpHNKeMo 6bAu5JYW0BgFXdunqD7wAnrwGtAJGLdEUqKgSQl834YBjsOpRJLEE9744yfD ascRayIHSgFabgmGrqjfflWiuZUSPFHAO.Z6ry.7w._GP4O9vk8OLgdkuJgV zxH6kLmG8rGnjQRQYvM7DjHuyQWvQXocLCpJoJ3QffoLZyVE5Yc4Na03bXGJ eyU_A8lHw81sqUzzvHOJBNkIS5svfR3VCwJfkr8hn83PUmosPOp6V7LV6YQP 3_5fvFtUqtuCDhV0.3g5Ux6MUFzdR4Edk2k4koFE- X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.17] (se@81.173.156.36 with plain) by smtp141.mail.ird.yahoo.com with SMTP; 28 Jun 2012 03:10:13 -0700 PDT Message-ID: <4FEC2D86.2040505@freebsd.org> Date: Thu, 28 Jun 2012 12:10:14 +0200 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Marcel Moolenaar 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> In-Reply-To: <4FEC22A0.9000109@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , freebsd-current , "Andrey V. Elsukov" 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 10:10:16 -0000 Sorry for following up to self, but ... I just noticed somebody else suggesting the same method (put GMIRROR configuration below Secondary GPT header), but I think there is a problem: If GMIRROR is used to mirror whole GPT partitioned drives, then you want the GPT sectors to be considered part of the mirror (to keep them identical when GPT partitions are created/modified on the mirrored disks). But the GMIRROR configuration must not be assigned to any GPT partition. Therefore it must be protected, either by hiding it (e.g. create a special partition to hold GEOM config data, just to reserve the space within GPT, since the configuration data will still be located by looking at specific sectors of the provider), or by skipping the sectors assigned to GEOM config data in the GEOM provider that interprets them (e.g. GMIRROR). The former only works if a GMIRROR (or GELI or whatever) is created on a disk that already has GPT headers (since these lead to the GEOM config data put before the Secondary GPT header and allow the GEOM config to be marked as a special partition in that header). The latter only works on disks without GPT headers, since the size of the provider will be smaller then the physical disk. Even with the last physical disks available for GPT, the GPT headers will probably not conform to the standard, since remapping of the sectors to hide the GMIRROR config will lead to different logical sector numbers for the secondary GPT header when looked at with or without GMIRROR loaded. I still think it is possible to find a layout, that does not violate the GPT standard (use last LBAs on disk, have self-referential information like own LBA address consistent with physical block numbers and block numbers presented to users of GMIRROR et.al.). Perhaps, GMIRROR could treat its configuration sector (that is placed at the sector just below the secondary GPT header) as read only. Requests may go to all sectors below and also to the area above the GMIRROR config sector used for the GPT header, to write it to all mirrored devices). But this is also ugly, since GPT must know to not assign the GMIRROR config sector to any partition (it is read- only for user requests, but writable on each individual drive in case of GMIRROR configuration or state changes, just as it is now). The reservation was best achieved by use of a specific GPT partition for the configuration data, for which GPT headers must exist, before the GMIRROR is created (or bith must be created at the same time, but that would mix GPT knowledge into GMIRROR). All of the above is ugly, U'm afraid :( Regards, STefan