From owner-freebsd-geom@FreeBSD.ORG Mon Jun 27 18:27:22 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDB9E106566C; Mon, 27 Jun 2011 18:27:22 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4A88FC1A; Mon, 27 Jun 2011 18:27:22 +0000 (UTC) Received: from sa-nc-common2-75.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.4/8.14.4) with ESMTP id p5RIRHTk096134 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 27 Jun 2011 11:27:23 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <4E08CA46.6030904@FreeBSD.org> Date: Mon, 27 Jun 2011 11:27:10 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <201106271810.p5RIABbI063810@freefall.freebsd.org> <4E08CA46.6030904@FreeBSD.org> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1084) Cc: freebsd-geom@FreeBSD.org Subject: Re: kern/157724: [geom] gpart(8) 'add' command must preserve gap for schemes 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: Mon, 27 Jun 2011 18:27:22 -0000 On Jun 27, 2011, at 11:21 AM, Andrey V. Elsukov wrote: > On 27.06.2011 22:10, Marcel Moolenaar wrote: >>>> There isn't a lot we can do about it. This is one of those >>>> historical mistakes that you can't fix without breaking with >>>> 30+ years of history. It's not worth the hassle IMO... >>> >>> Hi, Marcel >>> >>> I think we can just set gpt_first = 16 in g_part_bsd_create for new >>> tables and for existing tables also set gpt_first = 16 if all partitions >>> don not use this space. Something like this (untested): >> >> You may want to look at /etc/disktab. Are you willing to >> change all entries and deal with the consequences? :-) > > I do not see any problems here especially for gpart(8). > bsdlabel(8) does not use gpart(8), it still can write label directly to > the provider and it will be detected as before. You're creating inconsistent behaviour between bsdlabel and gpart and that will result in PRs. Whatever you do, keep consistency. If you really want to change the default behaviour of gpart, I suggest you first get rid of bsdlabel, fdisk, et al... -- Marcel Moolenaar marcel@xcllnt.net