[RFC] Remove requirement of alignment to track from MBR scheme

[Andriy Gapon]

on 25/05/2011 20:31 Warner Losh said the following:
> 
> On May 25, 2011, at 9:22 AM, Andriy Gapon wrote:
> 
>> on 24/05/2011 22:18 Andrey V. Elsukov said the following:
>>> On 24.05.2011 22:12, Marcel Moolenaar wrote:
>>>> 
>>>> On May 24, 2011, at 10:46 AM, Warner Losh wrote:
>>>>>> All I'm saying: be careful.
>>>>> 
>>>>> Agreed.  But the care should be on the creation side, not on the
>>>>> interpretation side.
>>>> 
>>>> ... as the original code was. We just need to add a sanity check to the
>>>> interpretation that filters out the real bogus information (resulting
>>>> in a partition with negative size).
>>> 
>>> A partition with negative size is not the one problem. Some time ago i
>>> found an easy reproducible bug, when BSD scheme creates providers with
>>> size bigger than parent provider size. Also  there was nothing against
>>> creation of overlapped partitions.
>> 
>> All the good points, IMO.
>> 
>>>> With respect to the creation:
>>>> 
>>>> Since out synthesized geometry is not necessarily the same as other
>>>> OSes, we could opt to synthesize a geometry that has a track size (=
>>>> sectors/track) that is a multiple of 8 (to play nice with 4K sectors),
>>>> and/or take the stripe size of the underlying GEOM into account. This
>>>> fundamentally doesn't change a thing for MBR, but has the side effect
>>>> of achieving some of the goals *and* automatically works for EBR as
>>>> well.
>>> 
>>> Today's devices do not report about their 4k sectors.
>>> 
>>>> Thus: rather than hack MBR and forgetting about EBR and other
>>> 
>>> I do not forget about EBR, PC98 and VTOC8. But we need begin from
>>> something.
>>> 
>>>> schemes, maybe we only have to tweak the geometry synthesis to give
>>>> people what they want without going over board. After 9.0 branched, we
>>>> can do a lot more knowing we have plenty of soak time...
>>> 
>>> Ok, i can revert all related changes and just do nothing :) It seems it
>>> is better solution :)
>> 
>> I hope that you won't take the easy road and won't give up. It's easy to
>> say "don't change things", but sometimes reality presses hard for a change
>> and there should be someone brave to make it.
>> 
>> I think that we are starting to reach some consensus here. Let me try to
>> summarize and check if this is what we indeed can agree upon.
>> 
>> For media tasting/validation: 1. Keep all the non-CHS LBA-based checks -
>> too large partitions, overlapping partitions, etc.  Perhaps add even more.
>> And, of course, with proper diagnostics. 2. Ditch all the checks based on
>> or involving CHS parameters.
> 
> 3. Stop rounding to the nearest track when READING MBR.  It is totally bogus,
> never necessary and no documentation of the MBR has been produced suggesting
> that you need to do this.  If you don't think it is valid, don't use it, but
> don't silently adjust it by a random amount leading to hard to track down
> bugs.

Your 3 should be a sub-case of my 2 as it involves CHS parameters.

>> For media creation, short term: 1. By default be compatible with present
>> behavior. 2. Provide a way for a user to disable all CHS-based
>> validations/adjustments of input parameters.
> 
> Do not adjust based on CHS at all.  The adjustments are almost always bogus.
> In fact, I can't think of a time when the MBR ending track should be adjusted
> when reading it from disk.  Can you provide justification for doing this
> that's backed up by some source that says "the MBR values are adjusted like
> ..." rather than "MBR values are aligned"   I've yet to find one that says
> this adjustment is anything but totally bogus on the read it from disk path.

I would agree with your suggestion, but I am trying to find a consensus with
Marcel and his POLA concerns.

>> 3. Keep all non-CHS validations and sanity checks, of course.
>> 
>> Long term (post-9 ?): 1. Change defaults to play nicer with modern disks
>> 
>> Longer term: 1. Possibly remove any CHS reference from all the code, kernel
>> and userland; invent better heuristic values for things like partitioning,
>> UFS newfs, etc.
> 
> You can't do that.  CHS are still needed for sunlabel and pc98 support.

OK.  Excluding the special cases.

-- 
Andriy Gapon