Date: Sat, 15 Feb 2014 19:28:06 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: Warren Block <wblock@wonkity.com> Cc: "Andrey V. Elsukov" <ae@FreeBSD.org>, Marcel Moolenaar <marcel@FreeBSD.org>, freebsd-geom@FreeBSD.org Subject: Re: Allowing arbitrary MBR slice alignment Message-ID: <73BC4100-2F81-41AD-BED7-0A920AE69C76@xcllnt.net> In-Reply-To: <alpine.BSF.2.00.1402151317320.45779@wonkity.com> References: <alpine.BSF.2.00.1402140918560.88288@wonkity.com> <29DD155A-790F-4D28-8FFF-FED5466BC336@xcllnt.net> <alpine.BSF.2.00.1402151317320.45779@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <wblock@wonkity.com> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?73BC4100-2F81-41AD-BED7-0A920AE69C76>