Date: Sat, 29 Nov 2008 19:30:29 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: Peter Wemm <peter@wemm.org> Cc: FreeBSD Arch <arch@freebsd.org> Subject: Re: RFC: making gpart default Message-ID: <68B9D78C-C0CF-4D64-AF53-C3736EEC8D23@mac.com> In-Reply-To: <e7db6d980811291356w54256e6du82350baf3c57d591@mail.gmail.com> References: <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com> <e7db6d980811282007j48903cdas289c302e1811a0b9@mail.gmail.com> <0F1745AA-611F-40B2-85F3-32FD78BC4B58@mac.com> <e7db6d980811291356w54256e6du82350baf3c57d591@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 29, 2008, at 1:56 PM, Peter Wemm wrote: > On Sat, Nov 29, 2008 at 1:32 PM, Marcel Moolenaar <xcllnt@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@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?68B9D78C-C0CF-4D64-AF53-C3736EEC8D23>