On Sat, 15 Feb 2014, Marcel Moolenaar wrote:
On Feb 15, 2014, at 1:27 PM, Warren Block <[email protected]> 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!
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "[email protected]"
