From owner-freebsd-arch@FreeBSD.ORG Thu Dec 4 02:39:07 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 96B441065670 for ; Thu, 4 Dec 2008 02:39:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 559988FC12 for ; Thu, 4 Dec 2008 02:39:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mB42b7Vs077892; Wed, 3 Dec 2008 19:37:07 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 03 Dec 2008 19:37:14 -0700 (MST) Message-Id: <20081203.193714.693830802.imp@bsdimp.com> To: peter@wemm.org From: "M. Warner Losh" In-Reply-To: References: <68B9D78C-C0CF-4D64-AF53-C3736EEC8D23@mac.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, xcllnt@mac.com 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: Thu, 04 Dec 2008 02:39:07 -0000 In message: "Peter Wemm" writes: : On Sat, Nov 29, 2008 at 7:30 PM, Marcel Moolenaar wrote: : > : > On Nov 29, 2008, at 1:56 PM, Peter Wemm wrote: : [..] : >> * 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)... : : I was more thinking of a man page note to warn of the issue. : : Also, in the gpt case, it might make sense in gpt partition table case : to round up the initial size to a power of 2. Right now we lose 34 : sectors from the beginning. Rounding it to 64 total at least gets us : to an even power of 2. UFS's frequent block size of 16K shouldn't : cross any underlying stripe boundaries in the usual case. This likely is a hang over from the MBR code that puts the first partition at one cylendar offset from the beginning to conform with the MBR conventions of (some?) Bioses that use that to get the parameters for the disk... Warner