Allowing arbitrary MBR slice alignment

[Warren Block]

The Problem

More and more disk devices have native 4K blocks.  The ability to align 
MBR slices to arbitrary values is consequently becoming more important. 
Misaligned filesystems might read or write at less than half the speed 
of aligned filesystems on the same disk.

Microsoft recognized this problem, and at least since the release of 
Vista in 2007, MBR-formatted disks created by Microsoft operating 
systems have started the first or main filesystem slice at block 2048 
(1M).  Despite the official standard for MBR alignment to CHS values, 
this second non-CHS but 4K-aligned de facto standard has become 
extremely common.

When MBR slices are created with gpart(8) on FreeBSD, their starting 
block and size are silently rounded to multiples of CHS values.  This 
happens even when specific values for -a (alignment) or -b (starting 
block) are given.  This silent rounding violates POLA.

Using 'gpart restore' to create or recreate slices can result in a 
restored disk with different slice sizes and locations.  Not only does 
that violate POLA, it has the potential to cause problems, like a 
supposedly identical partition being too small to hold a restore of the 
original data, or partitions being rounded to values that no longer all 
fit on the same disk:
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/169542

At present, the only way to create an MBR with 4K-aligned slices on 
FreeBSD is with fdisk(8), a legacy tool.

GPT is an alternative, but not a replacement.  Many systems with broken 
BIOS or UEFI implementations will not boot from GPT disks.  Metadata 
conflicts mean that some GEOM classes like gmirror(8) cannot coexist 
with the GPT backup table at the end of the disk.  MBR partitioning is 
still needed.


Suggested Solution

gpart(8) should be allowed to override the CHS rounding with -a and -b 
values when creating MBR slices.  If CHS rounding occurs when the 
options are not given, gpart(8) should give a warning that default 
values were used to avoid surprising the user.

The warning is really secondary.  Primarily and pragmatically, gpart(8) 
needs the ability to create MBR slices with arbitrary alignment so 
FreeBSD can deal gracefully with modern storage hardware.