Pomalejší diskový transfer při z LVM

Jedna z možných reakcí na příspěvek je, že ten rozdíl je v principu normální a neznamená nutně, že je něco špatně.
/dev/nvme0n1p2 je přímý blokový přístup na partition NVMe disku. Když čteš přes dd s iflag=direct, jde prakticky o velmi "tenkou" cestu přes kernel – skoro bez další logiky.
/dev/mapper/dokumenty je ale device-mapper vrstva (LVM). Každý I/O požadavek musí projít mapováním logical extent → physical extent. I když máš jen:
1 PV
1 VG
1 LV
tak pořád tam je device-mapper překladová vrstva. Ta přidává:
další lookup v mapping table
další blokovou frontu
další vrstvu v I/O stacku
U velmi rychlých NVMe disků (3+ GB/s) se tato režie začne projevovat docela výrazně. Typicky to dělá 10–40 % rozdíl v syntetických sekvenčních testech. Takže pokles z ~3.4 GB/s na ~1.9 GB/s není úplně překvapivý.
Další věci, které mohou výsledek ovlivnit:
Page cache / readahead
různé blokové zařízení mohou mít jiný read_ahead_kb.
I/O scheduler
NVMe často používá none, ale device-mapper může skončit s jiným nastavením.
Alignment extentů
pokud LV nezačíná přesně zarovnaně vůči NVMe erase/block hranicím.
dd není ideální benchmark
dd měří dost hrubě a je citlivé na overhead kernelu.
Pro realističtější test je lepší použít například:
fio --name=test --filename=/dev/mapper/dokumenty --rw=read --bs=1M --direct=1 --size=4G --numjobs=1
a totéž na /dev/nvme0n1p2.
Ještě můžeš zkusit zkontrolovat:

blockdev --getra /dev/nvme0n1p2
blockdev --getra /dev/mapper/dokumenty
a případně zvětšit readahead.
Shrnutí:
Ano, LVM přidává měřitelný overhead, který je na velmi rychlých NVMe vidět. V běžném provozu (filesystem, aplikace, random I/O) je ale rozdíl většinou výrazně menší než v tomto typu syntetického dd testu.