From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 2 15:14:37 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D5B8018E for ; Mon, 2 Jun 2014 15:14:37 +0000 (UTC) Received: from mail-forward5.uio.no (mail-forward5.uio.no [IPv6:2001:700:100:10::37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A2AF2165 for ; Mon, 2 Jun 2014 15:14:37 +0000 (UTC) Received: from exim by mail-out5.uio.no with local-bsmtp (Exim 4.80.1) (envelope-from ) id 1WrTwZ-0004Jl-DV for hackers@freebsd.org; Mon, 02 Jun 2014 17:14:35 +0200 Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WrTwF-0004Il-WD; Mon, 02 Jun 2014 17:14:16 +0200 Received: from shiva.uio.no ([129.240.203.14]) by mail-mx3.uio.no with esmtp (Exim 4.80) (envelope-from ) id 1WrTwF-0001kQ-I4; Mon, 02 Jun 2014 17:14:15 +0200 Message-ID: <538C94C5.4010305@thanelange.no> Date: Mon, 02 Jun 2014 17:14:13 +0200 From: Gyrd Thane Lange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Warren Block , "Andrey V. Elsukov" Subject: Re: fdisk(8) vs gpart(8), and gnop References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan> <538C6795.9080005@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 96D65408C06D34D29BE62C1C456B766054712699 X-UiO-SPAM-Test: remote_host: 129.240.203.14 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 348 max/h 6 blacklist 0 greylist 0 ratelimit 0 Cc: John-Mark Gurney , hackers@FreeBSD.org, Ian Lepore , "Michael W. Lucas" , Marcel Moolenaar 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: Mon, 02 Jun 2014 15:14:38 -0000 On 02. juni 2014 14:50, Warren Block wrote: > On Mon, 2 Jun 2014, Andrey V. Elsukov wrote: > >> On 01.06.2014 18:36, Warren Block wrote: >>> 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. >> >> Hello, >> >> I propose add a sysctl variable kern.geom.part.mbr.enforce_chs which is >> set by default. Merge it to all branches, then change it to zero in >> head/. User could change it when he wants to use alignment to 4k. >> And if there is no objections against this, I can do it. > > That's an interesting idea! If set, and the user asks for an alignment > that is not allowed with CHS, gpart can mention that sysctl in the error > message. Hi! I think a sysctl is a great idea! I'm supporting any idea that frees me from unnecessary CHS constraint. Even more so if I can specify my preference once and forget about it. (Currently I have to maintain local patches where the CHS calculations have been removed). Personally i think the current CHS constraint is positively wrong for modern disks that are LBA-based instead of CHS. Because of the supposed backwards compatible LBA-CHS-LBA roundtrip we end up using a bogus sector value of 63 instead of the native block size of the disk. I.e. using the block size is more in the spirit of the old CHS where the whole point of the calculation is to make it easier on the hardware. I'd be more supportive of keeping the CSH calculations if GEOM would only do it for detected non-LBA disks. I.e. only do it for hardware that needs it. Even without the CHS constraints in gpart, you can get the same effect with: gpart -a 63 (Assuming there aren't any disks in the wild with other geometries.) Best regards, Gyrd ^_^