512e, 4Kn and alignment: geometry is not durability

Two sector sizes, three familiar formats

A logical sector is an addressing unit; a physical sector describes device-level read/write granularity. The format names below distinguish these two sizes, not filesystem allocation units. Microsoft's historical compatibility guide documents this distinction; its old operating-system support table is not current deployment advice. [1]

On 512e, replacing part of a physical sector can require preserving its other bytes through read-modify-write. Seagate identifies both misalignment and small writes as causes, and discusses caching that combines updates. One host write therefore cannot simply be counted as one media RMW operation. [2]

One aligned partition, three different writes

These constructed examples assume a 512e interface, zero device alignment offset and direct linear mapping from the partition to the device. Offsets are byte offsets in that mapping, not arbitrary file offsets. The partition at 1 MiB begins at byte 1,048,576, which is divisible by 4096. This is address geometry, not measured media operations.

The second row touches only one physical sector but replaces one eighth of it. In the third, the partition is aligned yet the 4096-byte write straddles two sectors. Moving the partition cannot, by itself, fix every request shape. The fourth row uses a hypothetical start at 63 logical sectors: 63 × 512 = 32,256 bytes.

For device-relative start o, positive byte length n and physical-sector size P, the number of intersected sectors is:

floor((o + n - 1) / P) - floor(o / P) + 1

Whole-sector coverage additionally requires both o and n to be multiples of P. The calculation and example inputs generate this table at build time. Counts do not predict latency, command count, flash write amplification or the number of actual RMW cycles.

Read the topology at the layer being used

Linux 6.12 exposes distinct values for logical size, physical size, alignment offset and preferred I/O sizes. In stacked storage, the physical-block report can come from component constraints; it is not a probe of hidden NAND geometry. [3]

logical_block_size / physical_block_size

Addressing unit and reported physical write granularity.

alignment_offset

Byte displacement of a device or partition start from natural alignment.

minimum_io_size / optimal_io_size

Preferred request sizes for performance, not substitutes for addressing units; an optimal size of zero means none was reported.

Record the actual device or volume path with these observations. Applying the table's zero-offset arithmetic to a remapped, striped or differently aligned device without checking its mapping would change the problem being calculated.

Unbuffered access adds API-specific constraints. Microsoft's file-buffering documentation separates access sizes and offsets from memory-buffer alignment, and notes that disabling system buffering does not remove hardware caching. Check the API contract as well as the sector format. [4]

Geometry, atomicity and persistence are separate

“Physical sector” is sometimes described using the word atomic in documentation. That wording must not be extended into a promise that any application transaction survives power loss. Linux ext4's atomic-write documentation describes explicit capability, request and alignment requirements for torn-write protection. A sector-format label alone does not establish that contract. [6]

A device with volatile write-back cache can acknowledge an ordinary write before it reaches nonvolatile storage. Linux documents cache flush and Force Unit Access separately from address geometry. Correct alignment does not issue either operation. [5]

Keep the questions separate: is the request valid, does it cover whole physical sectors, is the required update atomic under the stated failure model, and when is completion durable? The fsync error review explains why a failed persistence request is not repaired by merely relabelling the data as written.

What a power-cut experiment actually demonstrated

Zheng, Tucek, Qin and Lillibridge (FAST 2013) tested 15 SSDs representing ten models using hardware power cuts. Their raw-device workload used direct, synchronized I/O. Section 5.3 reports mixed old/new data within 4 KiB records on three devices, termed shorn writes. This is evidence about the tested devices and fault workload, not a modern SSD failure rate or a benchmark comparing 512e with 4Kn. [7]

The practical inference is narrow: request geometry does not prove failure behavior. Keep the tested update boundary explicit when discussing a torn write. For today's Linux API contract, see the separate atomic-write analysis; it is not a replication of the 2013 experiment.

Method and limits

This is a primary-source synthesis with four deterministic address examples. No drive was written, repartitioned or benchmarked. The arithmetic has no cache, controller, filesystem or failure model; it does not estimate a slowdown or a failure probability. Linux 6.12 is the fixed ABI/cache reference. The separately linked ext4 documentation was reviewed on 12 October 2026; feature support must be checked against the deployed version.

Related corpus records: logical sector, physical sector, Advanced Format, 512e, 4Kn and partition alignment.

Primary sources

1. Microsoft: Advanced format disk compatibility update, sector formats and alignment issues
2. Seagate: Transition to Advanced Format 4K Sector Hard Drives, emulation and read-modify-write
3. Linux 6.12: stable sysfs block ABI, sector sizes and I/O topology
4. Microsoft: File buffering, alignment and file access requirements
5. Linux 6.12: Explicit volatile write back cache control
6. Linux ext4 documentation: Atomic Block Writes, requirements and semantics
7. Zheng, Tucek, Qin and Lillibridge: Understanding the Robustness of SSDs under Power Fault, FAST 2013, sections 4.2 and 5.3

Accessed 12 October 2026. Format definitions and mechanisms are sourced; example inputs and the interpretation checklist are Hesela's explanatory construction.