From owner-freebsd-geom@FreeBSD.ORG Mon May 23 16:32:48 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 1E5C5106566B; Mon, 23 May 2011 16:32:48 +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 BF8828FC17; Mon, 23 May 2011 16:32:47 +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 p4NGEo75003737 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 23 May 2011 10:14:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) From: Warner Losh In-Reply-To: <4DDA2F0B.2040203@yandex.ru> Date: Mon, 23 May 2011 10:14:45 -0600 Message-Id: <6DF62987-141B-4BB3-8E8D-9966EBAC828B@bsdimp.com> References: <4DDA2F0B.2040203@yandex.ru> To: "Andrey V. Elsukov" 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 10:14:57 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Marcel Moolenaar , Warner Losh , Poul-Henning Kamp , 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 16:32:48 -0000 On May 23, 2011, at 3:55 AM, Andrey V. Elsukov wrote: > Hi, >=20 > Since after r221788 many people report about lost of access to their > MBR partitions, i prepared new patch: > =09 > http://people.freebsd.org/~ae/mbr_geometry.diff >=20 > It removes from GEOM_PART_MBR constraints to alignment to track. > Now it is possible to create MBR partitions with exactly specified > start offset and size, and they will not be recalculated by kernel. >=20 > Also the patch adds new option "-g" to the gpart(8) utility. This > option can be specified for "add" and "resize" subcommands. > gpart(8) uses information about provider's "geometry" and does > partition alignment how it did before for MBR. >=20 > With these changes we give to users the choice how align their > partitions and also we still able to use some "broken" partition > tables. This looks fairly good. I have one or two minor questions... Since we don't have a good review tool for the project, this may seem a = little fragmented, but here goes: + if (pp->sectorsize > 4096) + return (EOPNOTSUPP); What's the motivation for this? This seems unrelated to the problem at = hand. It may be good, but 4096-byte sector size is very new and I'm not = sure MS-DOS can cope... :) There has been a long tradition in the MBR, = however, of supporting different sector sizes to allow old-old-old = school floppies that had 128 or 256 byte sectors to work, as well as = allowing the supper-compressed 1.77MB floppies to work with their = 1024-byte (or was that 2048-byte?) sectors. Not sure this really = matters for reading, and for writing this case is so far beyond the edge = I'm not even sure why I bring it up[*] In any event, I'd be tempted to use a #define for 4096 like = MBR_MAX_SECTOR_SIZE. - msize =3D MIN(pp->mediasize / pp->sectorsize, UINT32_MAX); + msize =3D MIN(pp->mediasize / pp->sectorsize, 2 * UINT32_MAX); Why this change? I think that it is in two places. The rest looks good. Thanks for coming up with such a complete patch = after my grumpy email... Warner [*] I guess old farts like to bring up this stuff to show how old they = are :)=