From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 1 16:53:28 2014 Return-Path: Delivered-To: hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 354289F0; Sun, 1 Jun 2014 16:53:28 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B38B2D71; Sun, 1 Jun 2014 16:53:27 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s51GrLU2003981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jun 2014 09:53:21 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s51GrL4o003980; Sun, 1 Jun 2014 09:53:21 -0700 (PDT) (envelope-from jmg) Date: Sun, 1 Jun 2014 09:53:21 -0700 From: John-Mark Gurney To: Ian Lepore Subject: Re: fdisk(8) vs gpart(8), and gnop Message-ID: <20140601165320.GV43976@funkthat.com> Mail-Followup-To: Ian Lepore , Warren Block , hackers@FreeBSD.org, "Michael W. Lucas" References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan> <1401634837.20883.74.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1401634837.20883.74.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 01 Jun 2014 09:53:21 -0700 (PDT) Cc: hackers@FreeBSD.org, "Michael W. Lucas" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 16:53:28 -0000 Ian Lepore wrote this message on Sun, Jun 01, 2014 at 09:00 -0600: > On Sun, 2014-06-01 at 08:36 -0600, Warren Block wrote: > > 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. > > Hmm. If it takes a special "do what I actually said" flag, that's okay > I guess. > > My problem with that thread is the implicit assumption that CHS > alignment is required by *something* but there's no evidence what that > something is, other than "MBR has always in the past been CHS aligned." > I don't have enough knowledge in this area to contradict that > assumption, I'm just always skeptical of "thus it was spoken in 1982 and > thus it will always be" as an argument against sensible change. Looking > at what's done on other modern OSes seems reasonable, for example. > > And then of course there's the matter of a conclusion (perhaps not 100% > satisfying, but workable) having been reached, and yet code was never > changed. Not that I can volunteer to do it right now, I'm already > overcomitted. Considering that I just brought up head on a 15+ year old machine, and was quite surprised how it "just worked", it is likely that we will still see machines that will break if CHS isn't handled properly... FreeBSD 11.0-CURRENT #2 r265148M: Sat May 3 00:19:19 PDT 2014 jmg@carbon.funkthat.com:/usr/obj/i386.i386/usr/src/sys/serbox i386 FreeBSD clang version 3.4 (tags/RELEASE_34/final 197956) 20140216 CPU: AMD-K6tm w/ multimedia extensions (200.46-MHz 586-class CPU) Origin="AuthenticAMD" Id=0x562 Family=0x5 Model=0x6 Stepping=2 Features=0x8001bf AMD Features=0x400<> real memory = 134217728 (128 MB) avail memory = 120770560 (115 MB) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."