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