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
