From owner-freebsd-geom@FreeBSD.ORG Sun Feb 16 03:28:15 2014 Return-Path: Delivered-To: freebsd-geom@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 38CCEAD5; Sun, 16 Feb 2014 03:28:15 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0497E1721; Sun, 16 Feb 2014 03:28:14 +0000 (UTC) Received: from macbook-air.wifi.xcllnt.net (atc.xcllnt.net [50.0.150.213]) (authenticated bits=0) by mail.xcllnt.net (8.14.7/8.14.7) with ESMTP id s1G3S6Z2033949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 15 Feb 2014 19:28:07 -0800 (PST) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_0C6238AE-2843-44C4-B449-12B6CCDF2ED7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: Allowing arbitrary MBR slice alignment From: Marcel Moolenaar In-Reply-To: Date: Sat, 15 Feb 2014 19:28:06 -0800 Message-Id: <73BC4100-2F81-41AD-BED7-0A920AE69C76@xcllnt.net> References: <29DD155A-790F-4D28-8FFF-FED5466BC336@xcllnt.net> To: Warren Block X-Mailer: Apple Mail (2.1827) Cc: "Andrey V. Elsukov" , Marcel Moolenaar , freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 03:28:15 -0000 --Apple-Mail=_0C6238AE-2843-44C4-B449-12B6CCDF2ED7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 15, 2014, at 1:27 PM, Warren Block wrote: >=20 >> Are you absolutely sure that 4K alignment resulted in non-CHS >> alignment? >=20 > gpart has never managed to create a slice starting at block 2048 for = me, either with -a4k or -b2048 or both. It always becomes block 2079, = the next multiple of 63. In effect, the value of -a is forced to 63 = when creating MBR slices, even when the user asks for something else. >=20 > Block 2079 is one block short of being 4K-aligned. I'm sorry, I probably wasn't clear. You suggest a change to gpart to allow non-CHS alignment, stating that 4K alignment is getting to be the standard. I have no problem accepting that 4K alignment is to be standard nowadays, but what I don't know is whether it's done at the cost of 30+ years of CHS alignment for the MBR scheme. If CHS is entirely dropped, then we just need to see what needs it (e.g. msdosfs) and make sure that once we stop CHS alignment we don't break our own code and don't break interoperability. There's a very good reason why the MBR scheme aligns to CHS and it's a deliberate choice to have it do so. All I'm asking is that we take the same care in removing that behaviour as there was when it was put in. >> There are alternatives to consider: >> 1. Don't change anything >> 2. Align to both CHS and the specified alignment (-a). >> 3. Add an option to allow precise control over the behaviour >> and thus avoid causing POLA violations when the MBR scheme >> suddenly behaves differently and creates incompatible >> slices. >=20 > #2 is only a partial solution. If an original MBR is not CHS-aligned, = 'gpart recover' would still create a new MBR that differs. The problem with recovery of a scheme that has ill-defined characteristics is that you'll have to make guesses and you can never guarantee that the recovered partition is identical to the original. One can argue that recovery without redundancy is something that should not even be attempted. > Is #3 what I suggested, or another method? I would expect that if the MBR scheme forces CHS alignment, that -a 4K would result in alignment for both. This is not the same as a specific option that tells the MBR scheme to not align to CHS at all. This would be a clear indication that 1) the user/operator takes responsibility for the end result and 2) that a change in default behaviour is asked for. gpart does allow for that with the -f option. It's for passing operational flags. For example ``gpart add -t freebsd -a 4K -f A ${dev}'' could be used to tell gpart that that alignment is to be taken from the user without enforcing other alignment. Note however that the alignment is actually handled by the user space utility, whereas the scheme-enforced CHS alignment is done by the kernel. Given the current implementation it's actually hard to have a defaukt behaviour of aligning to what the user asked for as well as to what the scheme enforces. --=20 Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_0C6238AE-2843-44C4-B449-12B6CCDF2ED7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlMAMEYACgkQpgWlLWHuifao6QCeItl+lTB8eAKliHbovy+DKMbJ C9wAn2GO/T/MjcPSBzKMoUq9hqqXO2sS =8zfI -----END PGP SIGNATURE----- --Apple-Mail=_0C6238AE-2843-44C4-B449-12B6CCDF2ED7--