Date: Mon, 02 Jun 2014 17:14:13 +0200 From: Gyrd Thane Lange <gyrd-se@thanelange.no> To: Warren Block <wblock@wonkity.com>, "Andrey V. Elsukov" <ae@FreeBSD.org> Cc: John-Mark Gurney <jmg@funkthat.com>, hackers@FreeBSD.org, Ian Lepore <ian@FreeBSD.org>, "Michael W. Lucas" <mwlucas@michaelwlucas.com>, Marcel Moolenaar <marcel@FreeBSD.org> Subject: Re: fdisk(8) vs gpart(8), and gnop Message-ID: <538C94C5.4010305@thanelange.no> In-Reply-To: <alpine.BSF.2.00.1406020642420.6998@wonkity.com> References: <20140601004242.GA97224@bewilderbeast.blackhelicopters.org> <20140601020053.GR43976@funkthat.com> <1401632369.20883.51.camel@revolution.hippie.lan> <alpine.BSF.2.00.1406010833290.24305@wonkity.com> <538C6795.9080005@FreeBSD.org> <alpine.BSF.2.00.1406020642420.6998@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ^_^
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?538C94C5.4010305>