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

[Nathan Whitehorn]

On 08/17/16 07:49, Slawa Olhovchenkov wrote:
> On Wed, Aug 17, 2016 at 07:36:00AM -0700, Nathan Whitehorn wrote:
>
>>> Your contention that the installer does not make policy decisions is
>>> equally spurious.  The installer makes many policy decisions, including
>>> the disk layout, the size of the swap partition, the name of the pool,
>>> the use of boot environments (which I dislike but am not allowed to
>>> override), the number of filesets and their mountpoints (which I also
>>> dislike and am not allowed to override either), etc.  The Unix
>>> philosophy is to push such decisions up the stack, not down.  The
>>> decision to align partitions on 4096-byte boundaries because we're not
>>> sure of the correct number but know for a fact that using a smaller
>>> number can have a huge impact on performance is the installer's to make.
>> Those are all things that the operating system does not have defaults
>> for: there are no tools like, say, gpart or newfs that layout disks in
>> any even vaguely automated way, and so no tools that would ever have
>> defaults for, say, the size of a swap partition except for the
>> installer. As such, the defaults are quite properly in the installer.
>> This is quite different: there are many tools that care about disk
>> alignment (say, gpart) and, by default, use the GEOM stripesize. The
>> installer is, after this patch, overriding what was meant to be a
>> system-wide default.
>>
>> My concern is that pushing this into the installer means that newfs,
>> zfs, gpart, etc., which all look at the GEOM stripesize for preferred
>> alignment, will still have suboptimal behavior on systems affected by
>> your patch. If we identified which drivers are reporting the wrong
>> alignment, we could fix the whole system at a go by changing it there.
>> As it is, we now have inconsistent default behavior for partitions
>> between tools (the installer and sade will now use a different alignment
>> than gpart on whatever systems you were trying to fix here) and between
>> pre- and post-installation environments.
> In long term, prefered aligment is forsing 4k (or may be more):
> install system on 512b [mirror] disk aligment now may be need required replace
> disk to 4k aligment. For more flexsible in future now best chois is 4k
> or more.

For future-proofing in such circumstances, it might be worth expanding 
the vfs.zfs.min_auto_ashift tunable into some global thing that the disk 
drivers (or geom_disk) read to round up the physical sector sizes they 
would otherwise report. That would ensure that gpart, zfs, etc. all 
behave consistently in such cases.
-Nathan