RFC: making gpart default

[Peter Wemm]

On Sat, Nov 29, 2008 at 1:32 PM, Marcel Moolenaar <xcllnt at mac.com> wrote:
> On Nov 28, 2008, at 8:07 PM, Peter Wemm wrote:
>
>> First, the 'gpart create' man page doesn't say what "scheme" is.
>
> Yes, the manpage needs some work.
>
>> After guessing, I tried:
>>
>> overcee# gpart create -s gpt /dev/twed1
>> gpart: 22 scheme 'gpt'
>>
>> What does that mean?  It turns out that I didn't have GEOM_PART_GPT
>> compiled in.
>
> Oops, forgot about parsing the error string...
> I just fixed it (rev 185454).
>
> The background: geom(8) simply prints the error that
> the kernel creates. This then requires that the kernel
> creates a user-friendly error message. This is not a
> good idea, because it side-steps things like i18n
> completely.
>
> So, for gpart I chose a different approach. The kernel
> uses a certain form for the error messages, which is:
>        <errno> [<parameter> 'value']
> The intend is to have user-space interpret what is
> meant and print something the user understands. This
> I forgot to do.
>
> For now, the translation is straight-forward, but it
> should not be too hard to improve upon it further.
>
> In general, geom(8) needs to do a bit more pre- and post-
> processing. It mostly just converts the command line into
> a gctl request and as such forces the user to do all the
> work. I'll work on that...

For the record, I like the idea of having a consistent control
interface.  I switched my machine to use GEOM_PART_MBR/BSD as well.

A couple of thoughts..

* Can gpart enumerate the list of schemes that the kernel supports?
If so, it could avoid the problem of having to interpret the kernel's
reaction to avoidable errors.

* The same goes for the list of 'geoms'.  'geom disk list' (among
other things) can find the providers list.  gpart could avoid passing
bogus provider names into the kernel in the first place.

* A couple of DWIM concessions would go along way.  Humanized number
suffixes, the ability to search for start addresses automatically,
find next free partition index etc.

I'd like this sort of thing to work:

# gpart add -s 4g -t freebsd-ufs twed1
created partition 3 from 1049088 to 8388608 on twed1.

# gpart add -t freebsd-ufs twed1
created partition 7 from 30409216 to 946361871 on twed1

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

The last issue isn't specific to gpart.  There was one device at work
where the fdisk free space starts at sector 63.  (31.5K).  When
creating 16K ufs blocks, the particular raid controller generated
*two* operations for every single file system read/write we did. UFS
helpfully did it all in what it thought were 16K transactions, (or
clustered 64K transactions) but were actually unaligned thanks to the
default mbr layout.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell