Date: Mon, 17 Feb 2014 10:40:22 -0700 (MST) From: Warren Block <wblock@wonkity.com> To: Marcel Moolenaar <marcel@xcllnt.net> 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: <alpine.BSF.2.00.1402170940590.38716@wonkity.com> In-Reply-To: <73BC4100-2F81-41AD-BED7-0A920AE69C76@xcllnt.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 15 Feb 2014, Marcel Moolenaar wrote:
> On Feb 15, 2014, at 1:27 PM, Warren Block <wblock@wonkity.com> wrote:
>>
>>> Are you absolutely sure that 4K alignment resulted in non-CHS
>>> alignment?
>>
>> 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.
>>
>> 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.
Agreed, that's entirely reasonable.
>>> 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.
>>
>> #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.
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.
>> 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.
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".
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.
> 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.
For me, alignment to the LCM of CHS and and -a value would be unexpected
when an explicit -a value was given. A warning would help, but on
FreeBSD I expect pretty much any program to use the values as supplied,
and at most, give a warning if they were really bizarre.
Thanks!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1402170940590.38716>