Výběr souborového systému pro servery s umělou inteligencí: XFS, ZFS, ext4 a proč Btrfs není na seznamu

Pokud jste právě utratili 40 tisíc eur za grafické karty, souborový systém, na který naléváte svá data, si zaslouží více než pět minut přemýšlení. Instalační program Ubuntu s radostí nainstaluje ext4 na všechno; pro mnoho úloh s umělou inteligencí je to správná odpověď, pro některé ne. Pokud si pro datovou sadu o velikosti 50 TB vyberete špatný souborový systém, ztratíte propustnost, data nebo se budete dívat, jak váš DataLoader nečinně sedí za úzkým hrdlem metadat.

Toto se zabývá tím, který souborový systém umístit kam na serveru s umělou inteligencí třídy Kentino (4–8 GPU, bootování z NVMe, scratching z NVMe, pomalejší hromadná úroveň). Ubuntu 22.04 / 24.04, jádro 6.x.

Krátká verze

Jednoodstavcová verze: ext4 pro OS, XFS pro hot scratch, ZFS, kde integrita záleží více než posledních 10 % propustnosti, žádné Btrfs v produkčním prostředí.

ext4 — nudné výchozí nastavení, které je obvykle správné

ext4 je již více než deset let výchozím souborem v Ubuntu, Debianu, Fedoře a RHEL. Dobře pochopený, obnovitelný pomocí fsck, 16 TB na soubor, 1 EB na svazek. Nic vzrušujícího – pointa.

Použijte ext4 pro root (každé Ubuntu live USB ví, jak to opravit; mnohem méně jich ví, jak importovat zpool), např. /homea pro úložiště imagí virtuálních počítačů v malém až středním měřítku.

Kde ext4 přestává být správný: široký paralelní I/O (jeho žurnál serializuje aktualizace metadat – dvacet pracovníků DataLoader na jednom úzkém místě svazku ext4 v žurnálu dlouho před saturací NVMe); jednotlivé obrovské soubory (zvládnuto, ale alokace rozsahu je méně přívětivá než XFS pro sekvenční soubory >100 GB – trénovací shardy, kontrolní body, video korpusy); snímky (nativně žádné; tenké snapshoty LVM fungují, ale jsou neohrabané).

mkfs.ext4 -L root /dev/nvme0n1p2

Pokud se ocitnete v situaci, kdy provádíte exotické ladění ext4 pro úlohu s umělou inteligencí, vybrali jste si špatný souborový systém.

XFS – správná odpověď pro data z rychlého scratchu a trénovací data

XFS byl souborový systém SGI pro vysoce výkonné sekvenční I/O operace na velkých polích. Toto dědictví téměř dokonale odpovídá úlohám umělé inteligence: velké soubory (trénovací shardy, parquet, tar soubory webových datových sad, kontrolní body), sekvenční čtení, mnoho paralelních čtecích jednotek, tolerance pro „zátěž regeneruje data“.

Co XFS dělá, co ext4 ne: alokační skupiny — svazek se rozdělí na 4–32 nezávislých skupin, které čtou a zapisují paralelně bez globálního zámku žurnálu, což je přesně to, co chce zavaděč dat s více pracovníky; zpožděná a spekulativní předběžná alokace takže velké sekvenční zápisy získávají souvislé rozsahy; žádný praktický limit velikosti souboru (8 EB); a xfs_growfs pro spolehlivé jednořádkové rozšíření po růstu RAIDu.

Co nedělá: žádné nativní snapshoty, žádné kontrolní součty dat souborů (metadata chráněná CRC od roku 2014), žádné zmenšování — pouze zvětšování.

Rozumné mkfs.xfs pro 8× NVMe RAID0 svazek s odkládací jednotkou, 64 KiB blok:

# su = stripe unit = chunk size; sw = number of data disks
mkfs.xfs -f -d su=64k,sw=8 -l size=512m -L scratch /dev/md0

# largeio + swalloc: behave for >1 MB I/O
# allocsize=1g: preallocate aggressively for big sequential writes
# noatime: save a write per read under heavy DataLoader load
mount -o noatime,largeio,swalloc,allocsize=1g /dev/md0 /scratch

noatime a largeio nejdůležitější. XFS na malých souborech je přijatelný, ale není jeho silnou stránkou – pro stovky milionů obrázků <16 KB je lepší je přebalit do souborových systémů webdataset / parquet / lmdb, nikoli do odkládacích souborových systémů (viz níže).

ZFS – správná odpověď, když záleží na integritě, snapshotech nebo kompresi

ZFS je souborový systém, správce svazků a softwarová RAID vrstva v jednom:

• Kontrolní součet od začátku do konce. Při čtení detekována bitová ztráta, tiše opravena s redundancí. Pro 50TB datovou sadu při dvouletém běhu na serveru Rust je to důležité; pro dočasné NVMe scratchování po dobu šesti týdnů už ne.
• Snímky a klony. Atomický, COW, prakticky zdarma. Snapshot před spuštěním, vytvoření klonu, vrácení zpět – pro pracovní postup ZFS existuje.
• Vestavěná komprese. lz4 výchozí nastavení; zstd pro lepší poměry. U textu / JSON / parketu je komprese obvykle zvyšuje efektivní propustnost, protože náklady na CPU jsou nižší než ušetřené I/O operace.
• ARC — vlastní čtecí mezipaměť založená na paměti RAM, oddělená od mezipaměti stránek Linuxu. Slavná „footgun“.
• Nativní RAID-Z — žádný mdadm.

Co to pro AI nedělá dobře: spotřebovává RAM (výchozí ARC je ~50 % systémové paměti – na serveru s 512 GB, který má 256 GB, ji jádro najednou nemá a trénovací úlohy očekávající mezipaměť stránek nebo obrovské stránky jsou ukončeny OOM; omezte ARC); ne nejrychlejší pro nezpracované sekvenční čtení (dobře vyladěný XFS na NVMe RAID0 poráží ZFS o 15–30 % – kontrolní součty a COW stojí skutečné cykly); ignoruje O_DIRECT (veškeré I/O operace jsou záměrně přes ARC – pro většinu úloh v pořádku, ale s GPUDirect Storage je tu těžká nekompatibilita).

Ladění ARC – jediný knoflík, který musíte nastavit

Na čerstvé instalaci Ubuntu + ZFS na 512GB serveru si ZFS nárokuje 256 GB pro ARC. zfs_arc_max při instalaci, ne po prvním OOM.

# Cap ARC at 64 GB. Bytes, not GB. 64 * 1024^3 = 68719476736
echo "options zfs zfs_arc_max=68719476736" | sudo tee /etc/modprobe.d/zfs.conf
echo 68719476736 | sudo tee /sys/module/zfs/parameters/zfs_arc_max   # apply now
sudo update-initramfs -u                                             # persist

Pravidlo: uzavřít ARC na 10–20 % systémové RAM na serveru s umělou inteligencí. Klasické dimenzování „2 GiB základ + 1 GiB na TiB“ je určeno pro úložné boxy; na boxu s umělou inteligencí je většina RAM vyhrazena pro váhy modelů, aktivace a mezipaměť stránek frameworku.

Rozumné rozvržení ZFS pro datovou vrstvu serveru s umělou inteligencí

# 8 × 16 TB SAS in two RAID-Z2 vdevs (6+2 each) — two vdevs give 2× IOPS
zpool create -o ashift=12 \
  -O compression=zstd -O atime=off -O xattr=sa -O recordsize=1M \
  data \
  raidz2 /dev/sd[a-h] \
  raidz2 /dev/sd[i-p]

# Datasets sized for their workload
zfs create -o recordsize=1M   data/datasets       # large training shards
zfs create -o recordsize=128k data/checkpoints    # mixed size
zfs create -o recordsize=16k  data/metadata       # small files (json, yaml)

zfs snapshot data/datasets@pre-run-2026-05-14
zfs rollback data/datasets@pre-run-2026-05-14

ashift=12 = 4 KiB bloky — pokud se to při vytváření poolu splete, nelze to opravit bez zničení poolu. recordsize=1M pro úlohy s velkými soubory (výchozí hodnota 128 KiB je pro víceGB shardy příliš malá). xattr=sa ukládá xattrs inline, což je mnohem rychlejší než výchozí nastavení.

Btrfs – obecně se vyhněte pro produkční AI

Btrfs má stejnou koncepční sadu funkcí jako ZFS – COW, snapshoty, kontrolní součty, vestavěný RAID. Na papíře ano; v praxi ho na serverech Kentino nedoporučujeme. RAID5/6 má známé chyby způsobující ztrátu dat, které samotný projekt označuje jako nepřipravené pro produkční prostředí (RAID1/10 jsou stabilní, paritní režimy nikoli); výkon se výrazně snižuje v důsledku fragmentace, kterou produkují úlohy AI (gradientní kontrolní body, mezipaměti); výkon snapshotů klesá strmě nad několika stovkami snapshotů, čehož pracovní postup na experiment dosáhne během čtvrtletí; a nástroje pro replikaci, monitorování a plánování čištění jsou méně vyspělé než ZFS nebo XFS. Na notebooku v pořádku. Pro server s více GPU a desítkami TB trénovacích dat zvolte XFS nebo ZFS.

Rozložení RAID – s čím spárovat souborový systém

Na discích s kapacitou 16 TB a více může obnova jednoho disku trvat 24–72 hodin a druhé selhání na discích stejné dávky v tomto časovém okně není zanedbatelné. Jednoduchá parita již není bezpečným výchozím nastavením. Použijte Z2/RAID6 nebo zrcadla.

Malé soubory versus velké soubory

Otázka, která lidi chytá do pasti víc než jakákoli volba souborového systému: Jak se váš souborový systém chová s 50 miliony 4KB obrazů ve stromu adresářů? Odpověď pro každý souborový systém zde: špatně.

Metadata na soubor (inode, dentry, časová razítka, xattrs) mají velikost 200–500 bajtů bez ohledu na velikost souboru – 50 milionů malých souborů spálí 10–25 GB metadat, než uloží bajt pixelových dat. Vzorec otevřít/číst/zavřít vázá stranu metadat a zastavuje workery DataLoader.

Oprava není v souborovém systému. Neukládejte malé soubory jako soubory. Zabalit do webdataset / tar / parquet / lmdb / hdf5 / safetensors a sekvenčně streamovat — PyTorch WebDataset a NVIDIA DALI to oba očekávají. Souborový systém pak vidí malý počet velkých souborů, v čemž je každý souborový systém zde dobrý. Pokud musíte udržovat jednotlivé soubory ve velkém měřítku, ZFS s recordsize=16k a xattr=sa je nejméně špatná možnost, ale skutečnou odpovědí je přebalit.

Přímý I/O, mezipaměť stránek a O_DIRECT

PyTorch se pro opakované epochy datových sad spoléhá na mezipaměť stránek Linuxu – epocha 1 z disku, epochy 2..N z RAM. Některé úlohy používají O_DIRECT obejít mezipaměť pro velké čtení, kde jsou data dotčena pouze jednou. Úložiště GPUDirect od NVIDIA jde ještě dál a využívá DMA pro NVMe → GPU přímo.

ext4 a XFS respektují O_DIRECT správně – zarovnaný přímý I/O, žádná mezipaměť stránek. ZFS ignoruje O_DIRECT (veškerý I/O přes ARC, záměrně): pro většinu úloh v pořádku, ale existuje závažná nekompatibilita s GPUDirect Storage. Zarovnání je důležité – vyrovnávací paměť a offset se musí shodovat s velikostí bloku zařízení (obvykle 4 KB).

Pokud plánujete použít úložiště GPUDirect Storage k napájení 8GPU boxu s plnou šířkou pásma, /data Musí být XFS na NVMe. Pokud nevíte, co je GPUDirect Storage a školení je vázáno na výpočetní výkon, zatím ho nepotřebujete.

Vícecestné NVMe

Dvouportový U.2 / E1.S NVMe port je k dispozici jako dvě cesty PCIe. Ovladač NVMe pro Linux podporuje nativní multipath (nvme_core.multipath=Y, výchozí v moderních jádrech), což umožňuje failover a round-robin vyvažování zátěže. Neviditelný na vrstvě souborového systému, ale důležitý pro failover (bez něj by selhání cesty/HBA způsobilo zmizení disku a souborový systém by zpanikařil) a šířku pásma (vícecestný disk U.2 dosahuje ~14 GB/s oproti 7 GB/s s jednou cestou).

cat /sys/module/nvme_core/parameters/multipath   # expect: Y
nvme list-subsys

Pro spotřebitelské M.2 NVMe (sestavy desktopové třídy 5090) není vícecestné připojení relevantní – pouze jedna cesta. Pro sestavy EPYC s 8 GPU a podnikovým U.2 / E1.S v backplane se dvěma řadiči jej nechte zapnutý.

Režie kontrolního součtu

Na 64jádrovém hostiteli s EPYC jsou náklady neviditelné. Na 16jádrovém Xeonu může ZFS při trvalém zatížení „krást“ 5–10 % efektivního CPU – to, zda na tom záleží, závisí na tom, zda je trénování vázáno na CPU při předzpracování (často ano pro vizuální systémy) nebo na GPU (často ano pro rozsáhlé LLM).

Upřímné rámování: ZFS zachycuje bitovou rotaci, které byste si jinak nikdy nevšimli, dokud se váš model netrénuje na jemně poškozených datech. Pro datovou sadu, kterou jste budovali šest měsíců, se 5–10 % vyplatí. Pro dočasné datové sady, které regenerujete každý týden, to neplatí.

NFS pro sdílené datové sady napříč uzly clusteru

Jakmile máte více než jeden server, stává se zajímavější, kde se datová sada nachází. Tři vzorce:

1. Zkopírovat do každého uzlu. Jednoduché, plýtvá kapacitou. Funguje pro <1 TB a ≤4 uzly.
2. NFS z vyhrazeného úložného serveru. Jedna kanonická kopie. Síť je úzkým hrdlem – minimum 25 GbE, 100 GbE pro trénování více uzlů.
3. Paralelní souborové systémy (BeeGFS, Lustre, WekaFS). Větší vztlak, váhy přesahují místo, kde NFS přepadá.

Pro 1–4 uzly je NFS správné. Server: XFS na RAID10 NVMe, exportováno přes NFSv4. Klient: připojit pomocí nconnect=8 paralelizovat napříč TCP spojeními.

# Server /etc/exports
/data/shared 10.0.10.0/24(rw,async,no_subtree_check,no_root_squash)

# Client
mount -t nfs -o vers=4.2,nconnect=8,proto=tcp,rsize=1048576,wsize=1048576 \
  storage01:/data/shared /mnt/shared

NFS přes 100 GbE s nconnect=8 poskytuje trvale 8–10 GB/s – což stačí pro 16 GPU při typickém vizuálním tréninku nebo LLM. Kromě toho BeeGFS / Lustre – o tom je jiný článek.

Kompletní příklad: 8GPU EPYC, 24 NVMe + 8 SAS

2× 480 GB NVMe  (boot)     → md RAID1   → ext4 → /
8× 7.68 TB NVMe (scratch)  → md RAID0   → XFS  → /scratch
8× 7.68 TB NVMe (data)     → md RAID10  → XFS  → /data
8× 16 TB SAS    (archive)  → 2× RAID-Z2 → ZFS  → /archive

ZFS ARC: 64 GB of 512 GB RAM. NVMe multipath: on. NFS export: /data over 100 GbE.

mkfs.ext4 -L root /dev/md0
mkfs.xfs -f -d su=64k,sw=8 -l size=512m -L scratch /dev/md1
mkfs.xfs -f -d su=64k,sw=4 -l size=512m -L data    /dev/md2

zpool create -o ashift=12 \
  -O compression=zstd -O atime=off -O xattr=sa -O recordsize=1M \
  archive raidz2 /dev/sd[a-h]

echo "options zfs zfs_arc_max=68719476736" > /etc/modprobe.d/zfs.conf
update-initramfs -u

Propustnost NVMe bez omezení, kde ji potřebujete, redundance tam, kde jsou data nenahraditelná, komprimované kontrolní součty pro všechno ostatní.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii, úložištích a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.