From owner-freebsd-arch@FreeBSD.ORG Sun Nov 30 03:30:50 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16A631065672 for ; Sun, 30 Nov 2008 03:30:50 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout012.mac.com (asmtpout012.mac.com [17.148.16.87]) by mx1.freebsd.org (Postfix) with ESMTP id F1F998FC0A for ; Sun, 30 Nov 2008 03:30:49 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.96] (209-128-86-226.BAYAREA.NET [209.128.86.226]) by asmtp012.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KB400AJZN2UXB40@asmtp012.mac.com> for arch@freebsd.org; Sat, 29 Nov 2008 19:30:32 -0800 (PST) Message-id: <68B9D78C-C0CF-4D64-AF53-C3736EEC8D23@mac.com> From: Marcel Moolenaar To: Peter Wemm In-reply-to: Date: Sat, 29 Nov 2008 19:30:29 -0800 References: <57809A37-B81C-4F50-A418-CD9303F06B72@mac.com> <0F1745AA-611F-40B2-85F3-32FD78BC4B58@mac.com> X-Mailer: Apple Mail (2.929.2) Cc: FreeBSD Arch Subject: Re: RFC: making gpart default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2008 03:30:50 -0000 On Nov 29, 2008, at 1:56 PM, Peter Wemm wrote: > On Sat, Nov 29, 2008 at 1:32 PM, Marcel Moolenaar > 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: >> [ '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