RFC: making gpart default

[M. Warner Losh]

In message: <e7db6d980812011605h18b40700v1043e376ef392365 at mail.gmail.com>
            "Peter Wemm" <peter at wemm.org> writes:
: On Sat, Nov 29, 2008 at 7:30 PM, Marcel Moolenaar <xcllnt at mac.com> wrote:
: >
: > On Nov 29, 2008, at 1:56 PM, Peter Wemm wrote:
: [..]
: >> * There should be some guidance or hints on laying out disks.  For
: >> example,  a gpart create -s gpt on a raid volume ends up with a start
: >> sector of 34 for the free space.  There should be a documentation hint
: >> to round up start sectors to a power of 2 and/or block size on a raid.
: >> eg: if you have a raid with 64K stripes, then move the start sector
: >> from 34 to 128.  Otherwise  we end up with file systems issuing
: >> transactions that can split across multiple raid stripes.  FWIW, I
: >> conveniently filled this hole with boot code.
: >
: > Hmmm... gpart(8) typically can't store this kind
: > of information on-disk, but other than that it
: > supports alignment/padding already. We just need
: > a way to tell gpart about it. Maybe this should
: > come from the provider (i.e. underlying geom)...
: 
: I was more thinking of a man page note to warn of the issue.
: 
: Also, in the gpt case, it might make sense in gpt partition table case
: to round up the initial size to a power of 2.  Right now we lose 34
: sectors from the beginning.  Rounding it to 64 total at least gets us
: to an even power of 2.  UFS's frequent block size of 16K shouldn't
: cross any underlying stripe boundaries in the usual case.

This likely is a hang over from the MBR code that puts the first
partition at one cylendar offset from the beginning to conform with
the MBR conventions of (some?) Bioses that use that to get the
parameters for the disk...

Warner