Navážu novým vláknem z ZFS na červnovou část diskuze z vlákna https://telekomunikace.cz/d/39807-proxmox-vs-harvester-cas-na-upgrade

Pokud by někoho zajímalo video Is ZFS Ready for NVMe Speed, tak dole je recall+chatgpt výcuc.

🧩 Tom & Allan Jude on ZFS + NVMe — Shrnutí rozhovoru

Rozhovor mezi Tomem z Learn Systems a Allanem Jude z Clara Systems je detailním, technicky hlubokým průvodcem současným stavem a budoucím směřováním ZFS v éře NVMe úložišť. Shrnuje historii, limity a výzvy přizpůsobení tradičního souborového systému moderním extrémně rychlým SSD diskům.

🧠 Úvod: Kontext a cíl rozhovoru

ZFS (Zettabyte File System) vzniklo kolem roku 2001, kdy existovaly pouze mechanické disky (HDD).
Dnes, o 25 let později, je potřeba přehodnotit jeho návrh kvůli nástupu NVMe SSD, jejichž výkon a latence dramaticky překonávají tehdejší hardware.
Cílem rozhovoru je vysvětlit, proč ZFS „nestíhá“ NVMe, kde jsou úzká hrdla a jak se komunita snaží systém modernizovat.

⚙️ Historie ZFS a omezení starého hardwaru

ZFS vzniklo v době, kdy byl disk o velikosti 100 GB luxus.
Mechanické disky zvládaly jen cca 200–250 IOPS, s průměrnou latencí 4 ms.
Proto ZFS navrhlo systém batchování zápisů: každých 5 s sesbírá data a zapíše je lineárně, aby minimalizovalo pohyb hlaviček.
Tento design (copy-on-write + sekvenční zápis) byl geniální pro HDD, ale dnes neodpovídá rychlosti SSD a NVMe.

📉 Fragmentace a zaplněné pooly

ZFS trpí tzv. free space fragmentation – při mazání zůstávají malé díry, do nichž se nové velké zápisy nevejdou.
Proto se doporučuje nenechávat pool úplně plný.
Moderní verze (např. od Clara Systems) zlepšily práci s tzv. gang blocks, které slučují malé segmenty, a přizpůsobily se větším sektorům (z 512 B → 4 KB).

🧮 SSD & NVMe: Flash Translation Layer (FTL)

NVMe/SSD používají Flash Translation Layer (FTL) – mapu mezi logickými a fyzickými bloky.
Kvůli „erase blockům“ (typicky 16–256 MB) musí SSD přepisovat velké celky, ne jednotlivé sektory.
ZFS s tím musí být v souladu – pokud zapisuje v nesladěných blocích, vznikají náklady na přemapování a přepis.
Výzva: různé disky = různé ideální velikosti zápisu → není univerzální ladění.

🧠 ZFS vs. NVMe – rozdíly v logice

| 🧩 Vlastnost         | 💽 HDD éra                     | ⚡ NVMe éra                     |
|----------------------|--------------------------------|--------------------------------|
| Průměrná latence     | ~4 ms                          | ~50 µs                         |
| IO plánování         | Batching každých 5 s           | Neustálé plnění front          |
| Zápisy               | Velké sekvenční bloky          | Mnoho paralelních IO           |
| Optimalizace         | Pevná pravidla                 | Směřování k auto-tuning        |
| Cíl ZFS              | Minimalizovat seek             | Minimalizovat CPU wait         |

NVMe je tak rychlé, že ZFS ztrácí čas „organizací“ IO operací.
Místo čekání a seskupování je lepší prostě posílat IO proudem — NVMe to zvládne rychleji.
Problém: ZFS musí zůstat kompatibilní i s HDD, takže nelze odstranit staré chování.

📊 Výkon v praxi

Streamingové úlohy (video, renderování): ZFS + NVMe zvládne více GB/s.
IOPS-intenzivní úlohy (DB, VM): ZFS využije jen _40–50 % potenciálu NVMe, protože fronty nejsou dostatečně plné.
Řešení: nové mechanismy front (dedikovaná vlákna, IO schedulery) pro udržení zařízení v zátěži.

🧭 Roadmapa vývoje

Cíl: „out-of-the-box optimalizace“ pro různé typy workloadů (databáze, VM, média).
Směr vývoje:
- Autodetekce typu disku (HDD / SATA SSD / NVMe / NVMe-oF).
- Vylepšený auto-tuning bez nutnosti manuálních zásahů.
- O_DIRECT podpora (od Los Alamos + Lawrence Livermore Labs): aplikace může číst/zapisovat mimo cache ARC.
- Dedicated IO threads pro udržování NVMe front plných.
- Zlepšení metadata struktury (větší label až 512 MB, více „Uber Blocks“, přímé informace o disku, VDEV properties).

💾 Spolupráce s výrobci SSD

Výrobci NAND (QLC/PLC) řeší přesnost zápisu a opotřebení buněk.
Disk by teoreticky mohl „požádat ZFS o opravu“ pomocí paritních dat – firmware ↔ filesystém komunikace.
Vyžaduje efektivnější mapování sektorů zpět na soubory bez prohledávání celého poolu.

📐 Sektorová velikost a kompromisy

Zvětšení sektoru z 4K → 16K šetří DRAM, ale:
- Zvyšuje „slack space“ (malé soubory zabírají víc místa).
- Komprese nemůže zapsat méně než 1 sektor.
Možné řešení: více malých bloků v jednom fyzickém sektoru.

🧾 Metadata, VDEV properties a autodetekce disku

Nové návrhy umožní uložit kompletní konfiguraci poolu přímo na disk.
Přidání uživatelských metadat – např. typ disku, náhradní díl, odkaz na objednávku.
Manuální označení disku jako HDD, SSD, NVMe, NVMe-oF, CXL atd.
Pomůže ZFS zvolit správné optimalizace.

🔮 CXL a budoucnost úložišť

CXL (Compute Express Link) umožní přístup k vzdálené paměti jako k lokálnímu úložišti.
Disky na CXL budou mít jiné latence než lokální NVMe → ZFS to bude muset zohlednit.
Směřujeme k vrstvenému úložišti („tiered storage“):
L1 cache → RAM → NVMe → SSD → HDD → pásky → cloud

🎬 Reálné nasazení ZFS

Hollywood – zpracování a archivace RAW filmových dat.
CERN, Lawrence Livermore, Los Alamos – superpočítače, vědecké simulace, fúzní výzkum.
ZFS je často použito jako backend pod Lustre.
Fakticky se stal standardem v enterprise i vědě.

🧩 Závěr

ZFS stále exceluje v robustnosti, kontrole integrity a efektivním využití HDD.
Pro NVMe už ale naráží na limity historických předpokladů.
Cílem současného vývoje je, aby ZFS „dohnalo hardware“ – využilo NVMe naplno, bez ztráty stability, a zároveň zůstalo univerzální pro všechny typy úložišť.

💬 „ZFS funguje na NVMe, ale NVMe je už tak rychlé, že ZFS nestíhá podávat práci.“
— Allan Jude