Installer formats LUKS with 512-byte sectors under a 4K-sector btrfs

[hegjon]

Summary

The encrypted install path creates the LUKS2 container with cryptsetup's default
512-byte encryption sector size. btrfs (the only filesystem the installer uses) always
does I/O in 4096-byte units, so every 4K block that crosses dm-crypt is split into eight
separate cipher requests, each with its own XTS tweak / IV derivation. Passing
--sector-size 4096 to cryptsetup luksFormat at install time removes that overhead
for free on a fresh install, but it cannot be changed afterwards without a full
cryptsetup reencrypt of the volume.

This is a performance / defaults issue, not a correctness bug. Data is safe either way.

Environment

• Omarchy: omarchy-dev 4.0.0.r2007.gd3d23fd-1, installed 2026-08-26 from the ISO
• Disk: NVMe, 512-byte logical/physical sectors as reported by the drive
• Result on the installed system:

$ lsblk -o NAME,TYPE,FSTYPE,PHY-SEC,LOG-SEC
NAME        TYPE  FSTYPE      PHY-SEC LOG-SEC
nvme0n1     disk                  512     512
├─nvme0n1p1 part  vfat            512     512
└─nvme0n1p2 part  crypto_LUKS     512     512
  └─root    crypt btrfs           512     512     <-- dm-crypt sector size = 512

cryptsetup luksDump /dev/nvme0n1p2 shows sector: 512 [bytes] on the data segment,
and btrfs on /dev/mapper/root has the default sectorsize 4096.

What the installer does today

From /var/log/archinstall/install.log on the installed machine:

Luks2 encrypting: /dev/nvme0n1p2
cryptsetup format: cryptsetup --batch-mode --verbose --type luks2 --pbkdf argon2id --hash sha512 --key-size 512 --iter-time 2000 --use-urandom luksFormat /dev/nvme0n1p2
...
Formatting filesystem: mkfs.btrfs -f /dev/mapper/root

No --sector-size is passed, so cryptsetup falls back to 512.

Why it matters

• btrfs never issues I/O smaller than its 4K sectorsize, and the partition is
  MiB-aligned by the installer, so a 4K crypto sector introduces no
  read-modify-write and no alignment hazards. It is strictly a win.
• With 512-byte sectors dm-crypt issues 8x as many skcipher requests per 4K block.
  The AES work is the same, the per-request overhead is not. On AES-NI hardware this
  shows up as a few percent on SATA and roughly 5-15% throughput (more in 4K random
  IOPS) on fast NVMe, where the CPU rather than the disk is the limit. The cryptsetup
  FAQ and the Arch wiki dm-crypt page both recommend 4096 for this reason.
• The window to fix it is install time. Changing it later means
  cryptsetup reencrypt --sector-size 4096, a full rewrite of the drive.

Reproduce

On any encrypted Omarchy install:

sudo cryptsetup luksDump /dev/nvme0n1p2 | grep sector    # expect 4096, get 512

Expected

New encrypted installs should format the LUKS2 container with a 4096-byte sector size,
matching the 4K I/O size of the btrfs filesystem placed on top of it.

[hegjon]

A side quest while working on PR #132. Below are numbers:

Measurements

Same commit built with and without the flag, encrypted unattended installs, luksDump confirming the sector on every target. Install = the BEGIN→END span the dashboard shows.

QEMU, 8 vCPU KVM, raw cache=none target on a 512/512 virtio disk, 3 installs per variant:

	install (mean ± sd)	disk layout	root image unpack	package strap
LUKS 512	51.8 ± 1.4 s	17.2 s	14.3 s	4.7 s
LUKS 4096	51.0 ± 0.9 s	16.0 s	14.5 s	4.9 s

ThinkPad X200 (Core 2 Duo, no AES-NI, SATA SSD 512/512, BIOS, USB stick), one install per variant:

	install	disk layout	root image unpack	package strap
LUKS 512	359.2 s	20.5 s	112.8 s	37.0 s
LUKS 4096	355.9 s	19.6 s	111.5 s	34.5 s

Within noise on both. The install writes through dm-crypt at ~220 MB/s (KVM) and ~28 MB/s (X200), nowhere near the CPU-bound regime on fast NVMe where the per-request overhead would show, so this is a defaults and alignment change, not a speed-up the installer can demonstrate.

Visible consequence

A fresh install reports sector: 4096 [bytes] in cryptsetup luksDump where existing systems report 512. Nothing else on the installed system differs. Existing volumes are untouched.

Notes

Stacked on #132: the luks.sh half lives in the vendored archinstall-bash that branch introduces. Can test with quattro branch later.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NJaUDuCBipUhuP1YYfEyuP