Tracking a known structural lever that's been deferred since the original podman-perf investigation: the host LUKS volume uses the legacy 512 B sector size, while the underlying hardware has 4 K physical sectors. Every write currently goes through a read-modify-write at the dmcrypt layer because of the size mismatch.
Why this matters for this machine specifically: even after applying every cheap fix we've packaged in this kit (Fix 1 dmcrypt no-workqueue, CPU performance pin on AC, systemd-oomd + zram, ext4 lazytime + data=writeback on /home), heavy multi-writer workloads (concurrent pip install + editor + browser) still hit w_await peaks of 2880 ms and PSI io_some of ~90 during peak. The remaining serialization is at the per-write dmcrypt layer where the 512 B → 4 K RMW lives. Per the diagnosis doc this migration is the biggest structural win left on the table — expected ~30–50 % write-latency reduction and notable variance compression.
Why this isn't done yet: requires a full LUKS reformat. There is no in-place migration path; the sector size is a property of the LUKS2 header set at luksFormat time. Backup + reformat + restore is the only safe path, which makes this a "next reinstall" job rather than a session-fix.
What to capture in the kit when this happens:
- the
cryptsetup luksFormat --sector-size 4096 … invocation in whatever bootstrap script the next install uses.
- a verification step (
cryptsetup luksDump … | grep 'sector size') suitable for the install hook.
- documentation note in the kit so future reinstalls don't silently regress to 512 B again.
Tracking a known structural lever that's been deferred since the original podman-perf investigation: the host LUKS volume uses the legacy 512 B sector size, while the underlying hardware has 4 K physical sectors. Every write currently goes through a read-modify-write at the dmcrypt layer because of the size mismatch.
Why this matters for this machine specifically: even after applying every cheap fix we've packaged in this kit (Fix 1 dmcrypt no-workqueue, CPU performance pin on AC, systemd-oomd + zram, ext4 lazytime + data=writeback on /home), heavy multi-writer workloads (concurrent
pip install+ editor + browser) still hitw_awaitpeaks of 2880 ms and PSIio_someof ~90 during peak. The remaining serialization is at the per-write dmcrypt layer where the 512 B → 4 K RMW lives. Per the diagnosis doc this migration is the biggest structural win left on the table — expected ~30–50 % write-latency reduction and notable variance compression.Why this isn't done yet: requires a full LUKS reformat. There is no in-place migration path; the sector size is a property of the LUKS2 header set at
luksFormattime. Backup + reformat + restore is the only safe path, which makes this a "next reinstall" job rather than a session-fix.What to capture in the kit when this happens:
cryptsetup luksFormat --sector-size 4096 …invocation in whatever bootstrap script the next install uses.cryptsetup luksDump … | grep 'sector size') suitable for the install hook.