File system blocks alignment
brde at optusnet.com.au
Wed Jan 6 19:59:14 UTC 2010
On Sat, 2 Jan 2010, Poul-Henning Kamp wrote:
> In message <20100102050843.GI3508 at 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
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.
More information about the freebsd-current