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

[Warner Losh]

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.

> 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.

> 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.

Warner