Sector sizes and partition alignment - 512n, 512e, and 4Kn · Linux

“Sector” means two different things and the difference is the whole lesson. There is the unit the kernel is allowed to address, and there is the unit the media can actually read or write. When those two numbers differ, every write smaller than the physical unit costs a read first - and a partition that starts in the wrong place makes every write smaller than the physical unit.

The symptom is not an error. It is a disk that delivers a fraction of its rated write throughput, on a host nobody has touched in two years.

Three numbers, three layers

Number	Set by	Reported as	Typical
Logical sector size	The device firmware	`LOG-SEC`, `blockdev --getss`	512 or 4096
Physical sector size	The media	`PHY-SEC`, `blockdev --getpbsz`	512 or 4096
Filesystem block size	`mkfs`	`blockdev --getbsz`, `tune2fs -l`	4096

That gives three device classes:

512n (native) - logical 512, physical 512. Old spinning disks and most virtual disks.
512e (emulated) - logical 512, physical 4096. The majority of enterprise SATA and SAS drives shipped in the last decade. The drive accepts 512-byte writes and internally performs a read-modify-write cycle on the 4096-byte sector that contains them.
4Kn (native 4K) - logical 4096, physical 4096. No emulation, no penalty, and a set of compatibility problems instead.

Read-only / Safedevice topology in one command— sda is 512e: LOG-SEC 512, PHY-SEC 4096. nvme0n1 is 4Kn with a 256 KiB optimal I/O size. mpatha is a SAN LUN reporting a 64 KiB minimum I/O - the array chunk size - and a 512 KiB optimal I/O, its stripe width. ALIGNMENT is the alignment_offset in bytes: anything other than 0 means the device is telling you LBA 0 does not sit on a physical sector boundary. lsblk -t prints the same topology set with no columns to remember.

$ lsblk -o NAME,SIZE,TYPE,PHY-SEC,LOG-SEC,MIN-IO,OPT-IO,ALIGNMENT,ROTA

NAME       SIZE TYPE PHY-SEC LOG-SEC MIN-IO OPT-IO ALIGNMENT ROTA
sda        1.8T disk    4096     512   4096      0         0    1
├─sda1       1G part    4096     512   4096      0         0    1
└─sda2     1.8T part    4096     512   4096      0         0    1
nvme0n1    3.5T disk    4096    4096   4096 262144         0    0
mpatha      10T disk    4096     512  65536 524288         0    0

Illustrative output

The same values come from sysfs, which is where scripts should read them because the column names have changed over lsblk versions and the sysfs paths have not:

Read-only / Safetopology from sysfs— grep . across several files prints each one with its path, which is more readable than five cat calls; grep may not print them in the order you listed. optimal_io_size of 0 means the device declares no preferred I/O size - normal for a plain disk, and a signal on a RAID LUN that the controller is not reporting its geometry, in which case mkfs cannot auto-tune and you must supply stripe parameters by hand.

$ grep . /sys/block/sda/queue/logical_block_size /sys/block/sda/queue/physical_block_size /sys/block/sda/queue/minimum_io_size /sys/block/sda/queue/optimal_io_size /sys/block/sda/alignment_offset

/sys/block/sda/queue/logical_block_size:512
/sys/block/sda/queue/physical_block_size:4096
/sys/block/sda/queue/minimum_io_size:4096
/sys/block/sda/queue/optimal_io_size:0
/sys/block/sda/alignment_offset:0

Illustrative output

The read-modify-write penalty

A 512e drive cannot write 512 bytes. Nothing can - the media works in 4096-byte units. When the kernel sends a 512-byte write, the drive reads the enclosing 4096-byte sector into its buffer, patches 512 bytes of it, and writes all 4096 back.

That is fine, because Linux filesystems use 4096-byte blocks and issue 4096-byte writes. As long as those blocks line up with the drive’s physical sectors, one filesystem block write is one physical sector write and the emulation costs nothing.

Misalignment breaks the line-up. If the partition starts at sector 63 - the old MBR cylinder convention - then filesystem block 0 starts 63 × 512 = 32256 bytes into the disk, which is not a multiple of 4096. Every 4096-byte filesystem block now straddles two physical sectors:

Why straddling costs exactly double

Take a 4096-byte filesystem write to a 512e drive whose partition starts at LBA 63.

Aligned case, partition starting at LBA 2048 (1 MiB):

The 4096-byte block covers LBAs 2048-2055, which is exactly one physical sector.
The drive writes one 4096-byte sector. One I/O.

Misaligned case, partition starting at LBA 63:

The 4096-byte block covers LBAs 63-70. Physical sector boundaries fall at LBA 56 and LBA 64.
The block therefore lives partly in physical sector 56-63 and partly in 64-71.
The drive must read both physical sectors, patch each, and write both back. Two reads and two writes where an aligned drive did one write.

On a spinning 512e drive that is roughly a 50% throughput loss on small random writes and a visible latency increase. On an SSD the equivalent penalty is write amplification against the erase block, which costs endurance rather than just speed.

Nothing reports this. There is no counter, no dmesg line, no SMART attribute for “your partitions are misaligned”. You find it by looking.

The 1 MiB convention

Every current partitioning tool starts the first partition at LBA 2048 - one mebibyte in. That number is not about 4K sectors specifically; it is chosen because 1 MiB is a multiple of every alignment anyone cares about: 4096-byte physical sectors, RAID chunk sizes up to 1 MiB, and SSD erase blocks.

Read-only / Safecheck one partition— align-check takes the alignment type (minimal or optimal) and a partition number. optimal checks against the device's optimal_io_size and physical block size; minimal checks only that the partition does not straddle a physical sector. A misaligned partition prints '1 not aligned' and is the answer to a disk that has always been slower than its siblings. The command reads the partition table and writes nothing.

$ sudo parted /dev/sda align-check optimal 1

1 aligned

Check every partition rather than assuming the first one is representative - a disk repartitioned in stages can have one aligned partition and three that are not:

for n in $(lsblk -no PARTN /dev/sda | tr -d ' '); do
  printf 'partition %s: ' "$n"
  sudo parted -s /dev/sda align-check optimal "$n"
done

Fixing alignment means recreating the partition, which destroys it

There is no parted --realign. Alignment is where the partition starts, so changing it means writing a new partition table with a different start LBA - which orphans every byte of the filesystem inside it. Nothing warns you afterwards; the partition simply contains no recognisable filesystem.

The only safe sequence is: verify a restorable backup, copy the data off, repartition, recreate the filesystem, copy the data back, and verify it. Treat it as a rebuild, not as a tuning change.

Before touching anything, capture the current table so the old layout can be put back if the copy turns out to be incomplete:

sudo sgdisk --backup=/root/sda-gpt.bin /dev/sda
sudo sfdisk --dump /dev/sda > /root/sda.sfdisk

And be honest about whether it is worth it. On a virtual disk backed by a file on a 4K-aligned host filesystem, or on any device whose PHY-SEC equals its LOG-SEC, misalignment costs nothing measurable. Measure the workload first; a rebuild is a real risk taken for what may be a theoretical gain.

When sector size stops being a performance question

Moving a filesystem between devices with different logical sector sizes is a correctness problem, not a tuning one.

XFS records its sector size in the superblock at mkfs time, and it cannot be mounted on a device whose logical sector size is larger than that value. An XFS created on a 512-byte-logical disk and then presented on a 4Kn device fails to mount:

XFS (sdb1): device supports 4096 byte sectors (not 512)
mount: /srv/data: mount(2) system call failed: Function not implemented.

The image is intact. The filesystem is fine. It simply cannot be addressed on that device. There is no in-place conversion - the fix is to recreate the filesystem with a matching sector size and restore into it, which means this must be discovered when the replacement hardware is specified, not during the restore.

The same shape of problem appears when a device-mapper or LVM stack combines devices with different logical sector sizes: the resulting device takes the largest logical block size of its members, so adding a 4Kn PV to a volume group full of 512-byte PVs can change the block size seen by filesystems that were built against the smaller one.

Record sector geometry with the backup, not just the data

Before a disk is replaced, capture what the old one reported. Two lines in the runbook prevent a restore that cannot mount:

lsblk -o NAME,PHY-SEC,LOG-SEC,MIN-IO,OPT-IO,ALIGNMENT > /root/dr/topology.txt
sudo xfs_info /srv/data >> /root/dr/topology.txt

xfs_info prints sectsz= and bsize= for the mounted filesystem, and sunit=/swidth= if it was built against a striped device. On ext4 the equivalent is sudo tune2fs -l /dev/sdb1, which prints the block size and any stride and stripe-width settings. Both are read-only.

Stripe geometry on RAID and SAN

MIN-IO and OPT-IO are how a RAID device advertises its geometry. mkfs.xfs queries the block device for sunit and swidth automatically when the device reports them, and mke2fs sets stride and stripe_width from the same source.

The case that needs attention is the device that reports nothing - OPT-IO of 0 on a LUN you know is striped. The controller is not passing the geometry up, so mkfs has nothing to auto-detect, and the filesystem is laid out as if the device were a single disk. Supply the values from the array documentation instead:

# chunk 64 KiB, 8 data disks: su=64k, sw=8
sudo mkfs.xfs -d su=64k,sw=8 /dev/mapper/mpatha

# the ext4 equivalent, in filesystem blocks of 4096 bytes:
# stride = 65536/4096 = 16, stripe_width = 16 * 8 = 128
sudo mkfs.ext4 -E stride=16,stripe_width=128 /dev/mapper/mpatha

Both of those create a filesystem and destroy whatever was on the device. Run them only against a LUN you have confirmed is empty, by its WWID rather than by its /dev/mapper alias.

Three numbers, three layers

The read-modify-write penalty

The 1 MiB convention

When sector size stops being a performance question

Stripe geometry on RAID and SAN

Knowledge check