From owner-freebsd-current@FreeBSD.ORG Wed Jan 6 19:59:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3745106568B for ; Wed, 6 Jan 2010 19:59:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx09.syd.optusnet.com.au (fallbackmx09.syd.optusnet.com.au [211.29.132.242]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1748FC1C for ; Wed, 6 Jan 2010 19:59:12 +0000 (UTC) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by fallbackmx09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o06HrlYZ017143 for ; Thu, 7 Jan 2010 04:53:47 +1100 Received: from c122-106-170-81.carlnfd1.nsw.optusnet.com.au (c122-106-170-81.carlnfd1.nsw.optusnet.com.au [122.106.170.81]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o06HrOQG004970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 04:53:27 +1100 Date: Thu, 7 Jan 2010 04:53:24 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Poul-Henning Kamp In-Reply-To: <67020.1262425354@critter.freebsd.dk> Message-ID: <20100107041552.D55224@delplex.bde.org> References: <67020.1262425354@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 06 Jan 2010 20:04:56 +0000 Cc: Miroslav Lachman <000.fbsd@quip.cz>, Thomas Backman , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Pieter de Goeje , Alexander Motin Subject: Re: File system blocks alignment X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 19:59:14 -0000 On Sat, 2 Jan 2010, Poul-Henning Kamp wrote: > In message <20100102050843.GI3508@acme.spoerlein.net>, Ulrich =?utf-8?B?U3DDtnJ > sZWlu?= writes: > >> Sysinstall, fdisk, gpart >> and bsdlabel should all display some fat warning if partition/label >> alignment is not, say at 256kB (a common stripe size, right?) > > You overlook that MBR/Fdisk requires bootable slices to start at a > "track". That means that the propper slice-alignmen typically > will be 8*63=504 sectors. Only with a misconfigured "track" size of 63 512-byte sectors, as is typical. The default track size was 32 for SCSI disks about 20 years ago. This would have given 16KB alignment even with other misconfiguration. The "track" size used to be fully configurable (by typing it in to the BIOS) in BIOSes slightly less than 20 years old. Now it is not so configurable. The latest BIOS that I've used (not very late) only offers a few settings like AUTO, 63, 240 (?) and 255 (?) IIRC. GEOM axed the kernel's support for figuring out the BIOS geometry from the MBR if possible, so utilities now default to the "firmware" "track" size (which is 63 for all ATA disks less than about 10 years old), instead of the "track" size that is actually being used by the BIOS and was used previously run partitioning utilities, if any. BIOSes should have corresponding support under their AUTO setting, starting about 20 years ago with SCSI BIOSes (SCSI BIOSes needed this more since non-SCSI disks normally used their hardware geometry, while SCSI disks never had a hardware geometry). With MBR entries created by different partitioning utilities with inconsistent geometries, the AUTO-detection of a nonstandard geometry is likely to be wrong. This caused considerable confusion about 20 years ago with SCSI BIOSes, since the (fake) geometry was used more so it was important to fake it consistently, but the BIOSes were too primitive or inconsistent across manufacturers (BIOS in the host adaptor with severe size constraints) to do it consistently. Why only 8*63 for 252KB (4KB) alignment? 512*63 would give 256KB alignment and waste almost 16MB. 16*32 would give 256KB alignment with only 256KB-sizeof(MBR) wastage. > Unless you want to explore how many BIOS'es still are stupid about > this... If they are stupid enough to want a track offset, then they may be stupid enough to want a track offset of exactly 1. I haven't noticed any BIOSes or OSes that are stupid enough to want a track offset, but I might not have noticed since I always use a simple partitioning scheme except for debugging. Bruce