Date: Sun, 1 Jun 2014 08:36:24 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Ian Lepore <ian@FreeBSD.org> Cc: John-Mark Gurney <jmg@funkthat.com>, hackers@FreeBSD.org, "Michael W. Lucas" <mwlucas@michaelwlucas.com> Subject: Re: fdisk(8) vs gpart(8), and gnop Message-ID: <alpine.BSF.2.00.1406010833290.24305@wonkity.com> In-Reply-To: <1401632369.20883.51.camel@revolution.hippie.lan> References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 1 Jun 2014, Ian Lepore wrote: > On Sat, 2014-05-31 at 19:00 -0700, John-Mark Gurney wrote: >> Michael W. Lucas wrote this message on Sat, May 31, 2014 at 20:42 -0400: >>> $SUBJECT have been two contentious points of discussion in private >>> mail, Twitter, the BSDCan bar track, and random people passing on the >>> street. I was very surprised at the number of knowledgeable people who >>> have different ideas on this and argue about it at length. >>> >>> I'm hoping to verify what seems to be correct. >>> >>> First, is fdisk EVER necessary? I *believe* that gpart's '-a 4k' >>> handles all alignment issues for the 512B/4KB sector issues. If you >> >> gpart's -a will not properly align MBR's slices due to enforced CHS... > > Maybe this is naive, but... can't we just *fix* that? Thread starts here: http://lists.freebsd.org/pipermail/freebsd-geom/2014-February/005835.html > For the longest time geom would warn about "geometry does not match > label" that had something to do with different parts of the code > calculating different CHS values. Eventually it was decided to remove > the unactionable message, and my vague memory is that the justification > was basically "because CHS is meaningless to geom and modern BIOSen." > > If there's some "it would cause problems on this ancient hardware that > only 3 people in the world use" (I'm usually one of those people -- we > support some old equipment in the field at $work), then maybe there > could be a flag that enables the old CHS alignment behavior. Short form of above: gpart is supposed to hide and handle underlying GEOM issues, so it needs an override to be able to create these "non-standard" MBRs with slices aligned to arbitrary values.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1406010833290.24305>