RFC: making gpart default

[John Baldwin]

On Wednesday 03 December 2008 09:37:14 pm M. Warner Losh wrote:
> 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...

No, the way GPT works, you have a PMBR at sector 0, then immediately following 
that you have the Primary partition table in the next N sectors (the first 
sector in the table has a header that contains the size of the table).  Then 
you have a backup Secondary partition table in the last N sectors of the disk 
as well.  At least with the old gpt(8) tool you could actually tell it how 
big of a table to make when you created a GPT, and I imagine gpart probably 
can do the same.

-- 
John Baldwin