Date: Mon, 17 Feb 2014 11:08:29 -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: <868C9E58-8039-4782-BC74-5C820D1B4F5C@xcllnt.net> In-Reply-To: <alpine.BSF.2.00.1402170940590.38716@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> <73BC4100-2F81-41AD-BED7-0A920AE69C76@xcllnt.net> <alpine.BSF.2.00.1402170940590.38716@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_B739D10C-E07C-40CB-939F-216EB463D05B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Feb 17, 2014, at 9:40 AM, Warren Block <wblock@wonkity.com> wrote:
>=20
>>>> 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.
>>=20
>> 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.
>>=20
>> One can argue that recovery without redundancy is something
>> that should not even be attempted.
>=20
> Sorry, s/recover/restore/. Let me try again:
> 'gpart restore' should recreate the partitioning as shown in the =
input,
> or give an error if it is not possible. Either of these is preferable
> to creating partitioning which has been silently adjusted.
Agreed.
>=20
>>> Is #3 what I suggested, or another method?
>>=20
>> 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.
>>=20
>> gpart does allow for that with the -f option. It's for
>> passing operational flags.
>>=20
>> 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.
>=20
> That would be better than the current situation, although the second =
flag ends up saying "and this time, really do what I said to do".
>=20
> When the user supplies -a or -b values, I suggest it implicitly means =
"...and override any default assumptions". The current behavior could =
be retained by supplying -a63, although admittedly that might not work =
all the time. Maybe a special value of '-a chs'? Or actually, just the =
default when -a or -b are not supplied.
This is where things get tricky...
First there's architecture and layering. The whole point gpart
is to abstract the details of the actual implementation and
present is simple, be it low-level, and common user interface.
Things like '-a chs' are meaningless to non-MBR schemes and as
such become warts in the interface and usage. That's ugly.
It's for this reason that gpart uses aliases for partition
types and not the "raw" and scheme-specific encoding. It is
still possible to use the scheme-specific encoding, but it's
done in a way that makes it clear that the interpretation of
the partition type is scheme-specific.
Any scheme implementation can impose whatever is necessary to
create a valid partitioning. For MBR this means that partitions
are always aligned to CHS. In combination with "-a 4K" is would
assume that this means both CHS *and* 4K alignment because the
user may not be aware (and should not have to worry) about any
implied alignment or rounding. Having "-a 4K" imply that the
scheme implementation is to trust that the user knows what she
is doing and knows about scheme-specific constraints is counter
to the design and in practice absolutely false. It's for this
reason that it's better to introduce a special flag (just like
the common "force" flag) that serves as the unambiguous signal
that the user takes full responsibility for the results.
I don't think therefore that a special flag will say "and this
time do what I say". It'll will say "Set the usage mode from
'cooked', to 'raw' and take everything I say literally". That's
a good way to keep both sides of the interface from having to
guess.
In short: Don't revert the design and intent of gpart. Let it
be the common interface to all partitioning schemes. This means
that you want be be able to say "-a 4K" or "-b 2000" without
regard for the scheme and know that the scheme will round or
adjust accordingly. The gpart utility will lose its power if
that is being meddled with, because it's power comes from the
fact that you do not have to know the particulars of the scheme
in use, nor even the scheme being used in order to work with it.
This is key in having it be scriptable.
You want a way to let gpart (and the kernel) know that you are
aware of the scheme and are going to do things that should not
be interpreted as coming from behind a "veil of ignorance" so
to speak.
--=20
Marcel Moolenaar
marcel@xcllnt.net
--Apple-Mail=_B739D10C-E07C-40CB-939F-216EB463D05B
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
iEYEARECAAYFAlMCXi0ACgkQpgWlLWHuifa4aACfcS0Yl+oIoV/ZROmmKkMkTP6S
kvIAn19DvtYkmlh1qF5tyuGavxCmDb+T
=JpvV
-----END PGP SIGNATURE-----
--Apple-Mail=_B739D10C-E07C-40CB-939F-216EB463D05B--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?868C9E58-8039-4782-BC74-5C820D1B4F5C>