RFC: making gpart default

[Marcel Moolenaar]

On Nov 29, 2008, at 1:56 PM, Peter Wemm wrote:

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

Not yet, but can be added fairly easily. The kernel
has a list of supported schemes, which it just needs
to export in the XML. In that case, and with each
scheme a kernel module, gpart(8) can also try to
load the kernel module on demand...

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

True. The list of GEOMs is already in the XML, so
it can be checked up-front by gpart(8). This also
aligns well with stripping /dev/ from the provider
and geom name.

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

Yup. I considered this already and just haven't
gotten around to work on it.

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

-- 
Marcel Moolenaar
xcllnt at mac.com