From owner-freebsd-geom@FreeBSD.ORG Wed Feb 7 21:50:15 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2772016A400 for ; Wed, 7 Feb 2007 21:50:15 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.184]) by mx1.freebsd.org (Postfix) with ESMTP id CCC3913C494 for ; Wed, 7 Feb 2007 21:50:14 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/8.12.11/smtpout14/MantshX 4.0) with ESMTP id l17LXi9O015963; Wed, 7 Feb 2007 13:33:44 -0800 (PST) Received: from [192.168.1.2] (c-67-164-11-148.hsd1.ca.comcast.net [67.164.11.148]) (authenticated bits=0) by mac.com (Xserve/smtpin07/MantshX 4.0) with ESMTP id l17LXfBw022020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Feb 2007 13:33:43 -0800 (PST) In-Reply-To: References: <45C98F32.20308@enderzone.com> <99017.1170839681@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A84E040-670F-456F-BA3B-338FC815B0A6@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Wed, 7 Feb 2007 13:32:13 -0800 To: Ivan Voras X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-geom@freebsd.org Subject: Re: New g_part class X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2007 21:50:15 -0000 On Feb 7, 2007, at 1:16 PM, Ivan Voras wrote: > Ok, the need for sysctl kern.geom.debugflags=16 arises because the > live > system to be used as master has mounted partitions, and those > partitions > span the whole disk, thus conflict with gmirror which wants to use the > last sector. Since using the last sector for metadata is The Official > Way, how about making such conflicts easy to avoid, like for example > building additional logic in g_part to create partitions one sector > smaller than the container? This cannot generally be done. The GPT partition scheme puts a backup of the header sector in the very last sector on disk, as per the specs. -- Marcel Moolenaar xcllnt@mac.com