[parted-devel] [PATCH 5/6] libparted: handle logical partitions starting immediately after the EBR

[John Gilmore]

> To allow for a partition to start on the first sector following the
> MBR, which is a perfectly legal configuration.

It's legal but may be suboptimal, depending on your hardware.

The issues relate to block sizes on the physical medium, which we can
no longer assume is a rotating magnetic disk drive.  When partitions
are misaligned such that a single e.g. 8k byte write ends up crossing
into multiple flash erase blocks, it's slower, because it makes a lot
more overhead in the flash translation layer, and it wears out the flash
more quickly.  This is also a problem with disk drives that have 4k or 8k
sectors on the drive, but offer a standard 512-byte read/write interface.
A misaligned write, even of the physical sector size, involves two reads,
two writes, and a modify sequence in between.  An aligned write
requires just a write.  Drives with larger sectors are popular at the
high end, and are coming to all price and capacity ranges, because they
very cheaply improve both drive capacity and error recovery. 

Also, since drive images and file systems tend to get copied around
from drive to drive, we try to make the partition alignment work for
all common drive configurations that the data we're creating might get
copied onto.  With modern drive sizes, how small we can make the
alignment padding before the first file system begins is not an
important issue.  Let's say we lose 1 megabyte of storage (by putting
the first partition at 1MB instead of at about sector 6, shortly after
the MBR).  The overhead of losing 1MB in a gigabyte memory stick is
0.1%, quite tolerable.  On a 250-GB disk drive, the overhead is
1/250th of 0.1% - unnoticeable.  This overhead is a downside.  The
upside is that this eliminates many kind of interoperability problems
for users, and also tends to future-proof the code against many
different possible future block sizes (any power of 2 from 512 bytes
to 1,048,576 bytes).  Getting high speed on current and future hardware
was worth sacrificing the thousandths of a percent of overhead on 
typical drives.

	John