svn commit: r304142 - head/usr.sbin/bsdinstall/partedit

[Nathan Whitehorn]

On 08/17/16 10:56, Andriy Gapon wrote:
> On 17/08/2016 19:36, Nathan Whitehorn wrote:
>> OK, so then what is the solution here? We have a number of tools that need to
>> know this information: gpart, sade, bsdinstall, zfs, graid, etc. If we want to
>> have a consistent set of defaults -- for example, to use 4K across the board,
>> which I think is a good idea -- there should be a central place to set this that
>> does not involve hacking a variety of independent tools. Do you disagree?
>>
>> I don't care how that happens. It happens that the way we currently encode this
>> is geom stripesize. If we feel like we can't get this right in drivers, then we
>> should provide a tunable to set a minimum default alignment. You could implement
>> this in lots of different ways. But having static values hardcoded in random
>> places that makes similar tools (sade, gpart) behave inconsistently cannot
>> possibly be the answer.
>>
>> This is my point, from beginning to end. Is there any reason -- at all -- that
>> we should prefer per-tool one-off changes to fixing the central mechanism we
>> already have to give consistent results that we think are reliable?
> It would be perfect to get a correct description of a disk and to do that in
> central place.  But still I, as a user / administrator, want to be able to
> _force_ the alignment that I want when I partition a disk, create a filesystem,
> etc.  That is, even if the kernel reports the perfectly correct information and
> the tools know how to automatically do what's best for me, I still want to eb
> able to override.  And I think that installers and administrative tools should
> provide a way to do that.  And many already do, e.g. 'gpart add -a X'.
> So, I do not see how striving for the better disk detection (in a central place)
> and having more knobs in the administration tools are mutually exclusive or
> conflicting goals.
>
> Just my two bits.
Agreed 100%. The issue here is that this kind of patch unconditionally 
overrides the kernel in an unsettable way. I think the right scheme is:
1. Try to get the real values as much as possible.
2. Provide a global hint to all tools that you want some value (e.g. 4K) 
unless the drivers are *sure* it's the wrong answer.
3. Have options in individual tools to force other values.

We have (1), though it can probably be improved, and (3) and just need (2).
-Nathan