Re: [PATCH v2 0/1] dm-crypt: allow encryption sector size up to PAGE_SIZE

[Mikulas Patocka <mpatocka@redhat.com>]

On Wed, 23 Sep 2026, Itai Handler wrote:

> A torn sector is possible today
> -------------------------------
> 
> Consumer NVMe are generally shipped with 512-byte logical blocks and
> stay that way in use. Installing Linux does not change it: partitioning
> and mkfs work inside the logical blocks the drive already exposes.
> Changing the block size is a separate low-level operation - nvme format
> with a different LBA format - which is destructive, which no installer
> performs, and which a drive may not offer at all.
> 
> The machine I am writing from is one: a Samsung PM981a carrying a
> complete Ubuntu install - GPT, EFI partition, /boot, and the rest of the
> drive as LUKS over dm-crypt with LVM and ext4 on top - and it still
> reports logical_block_size = physical_block_size = 512, with no
> atomic_write_* attributes at all. The dm-crypt device on it reports a
> 512-byte logical block too.

I did some benchmarking some times ago - and all the SSDs that I tested 
had worse IOPS for sub-4k writes than for 4k-aligned writes. This means 
that the SSDs have 4k sectors internally and do read-modify-write cycle 
for sub-4k writes.

The SATA standard doesn't specify well what 'physical block size' should 
mean on SSD - the result is that some SATA SSDs report physical block size 
512 and some 4k.

The SSDs have remapping table that maps logical blocks to locations in the 
flash chips - and RAM is expensive, so I doubt that any SSD vendor would 
put 8 times more RAM on the SSD in order to map 512-byte sectors 
individually.

Mikulas