From owner-freebsd-geom@FreeBSD.ORG Mon May 23 17:44:05 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 82C5C1065675; Mon, 23 May 2011 17:44:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1E90D8FC08; Mon, 23 May 2011 17:44:05 +0000 (UTC) Received: from [10.30.101.53] ([209.117.142.2]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p4NHcfNR004824 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 23 May 2011 11:38:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 23 May 2011 11:38:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9ED563AB-7B35-40F4-A33E-015317858401@bsdimp.com> References: <4DDA2F0B.2040203@yandex.ru> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Mon, 23 May 2011 11:38:43 -0600 (MDT) Cc: "Andrey V. Elsukov" , Warner Losh , Poul-Henning Kamp , Marcel Moolenaar , freebsd-geom@freebsd.org Subject: Re: [RFC] Remove requirement of alignment to track from MBR scheme 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, 23 May 2011 17:44:05 -0000 On May 23, 2011, at 10:35 AM, Marcel Moolenaar wrote: > I think we've had enough rushed and ill thought-out changes going > in already and I can see that not aligning MBR partitions on a track > boundary is potentially perceived as a PITA violation. I can understand only generating MBRs on a track boundary. After all, = that's being conservative about what we generate. However, we have to = accept MBRs that don't end on a track boundary because that's the = de-facto standard. What we're doing now, adjusting the size to the = track boundary, is flat out wrong. Either we should accept the size or = reject it. There's nothing I've ever seen to suggest that one should = adjust it in any way when we encounter one that's not track aligned. = The behavior of Windows, Linux and MacOS suggests the proper thing to do = is just accept it. The 16GB drive I have also suggests that we just = accept it, at least in some cases. I'm all for carefully moving forward. There were parts of the patch = that seemed to be over-reaching. Personally, I'd just do something like the following since it reflects = what others do and implements the de-facto meaning of the MBR: Index: sys/geom/part/g_part_mbr.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/geom/part/g_part_mbr.c (revision 222183) +++ sys/geom/part/g_part_mbr.c (working copy) @@ -473,7 +473,7 @@ =20 basetable->gpt_entries =3D NDOSPART; basetable->gpt_first =3D basetable->gpt_sectors; - basetable->gpt_last =3D msize - (msize % basetable->gpt_sectors) = - 1; + basetable->gpt_last =3D msize - 1; =20 g_free(buf); return (0); Warner