Výber súborového systému pre servery s umelou inteligenciou: XFS, ZFS, ext4 a prečo Btrfs nie je na zozname

Ak ste práve minuli 40 000 eur na grafické karty, súborový systém, na ktorý nakladáte svoje dáta, si zaslúži viac ako päť minút premýšľania. Inštalačný program Ubuntu s radosťou nasadí ext4 na všetko; pre mnohé úlohy umelej inteligencie je to správna odpoveď, pre niektoré nie. Ak si vyberiete nesprávny súborový systém pre 50 TB dátový súbor, stratíte priepustnosť, stratíte dáta alebo budete sledovať, ako váš DataLoader nečinne sedí za úzkym hrdlom metadát.

Toto sa týka toho, ktorý súborový systém umiestniť kam na serveri s umelou inteligenciou triedy Kentino (4–8 GPU, bootovanie z NVMe, scratchovanie z NVMe, pomalšia hromadná vrstva). Ubuntu 22.04 / 24.04, jadro 6.x.

Krátka verzia

Jednoodstavcová verzia: ext4 pre OS, XFS pre rýchle scratchovanie, ZFS, kde integrita dôležitejšia ako posledných 10 % priepustnosti, žiadne Btrfs v produkcii.

ext4 — nudné predvolené nastavenie, ktoré je zvyčajne správne

ext4 je už viac ako desať rokov predvoleným súborom v systémoch Ubuntu, Debian, Fedora a RHEL. Dobre pochopený, obnoviteľný pomocou fsck, 16 TB na súbor, 1 EB na zväzok. Nič vzrušujúce – pointa.

Použite ext4 pre root (každý Ubuntu live USB vie, ako to opraviť; oveľa menej vie, ako importovať zpool), pre /homea pre úložiská obrazov virtuálnych počítačov v malom až strednom rozsahu.

Kde ext4 prestáva byť správny: široký paralelný I/O (jeho žurnál serializuje aktualizácie metadát – dvadsať pracovníkov DataLoader na jednom úzkom mieste zväzku ext4 v žurnále dávno pred saturáciou NVMe); jednotlivé obrovské súbory (spracované, ale alokácia rozsahu je menej priateľská ako XFS pre sekvenčné súbory > 100 GB – trénovacie shardy, kontrolné body, video korpusy); snímky (natívne žiadne; tenké snímky LVM fungujú, ale sú neohrabané).

mkfs.ext4 -L root /dev/nvme0n1p2

Ak sa pri práci s umelou inteligenciou ocitnete v situácii, keď ladíte exotický ext4, vybrali ste si nesprávny súborový systém.

XFS – správna odpoveď na dáta z rýchleho scratchu a tréningové dáta

XFS bol súborový systém SGI pre vysokovýkonné sekvenčné I/O operácie na veľkých poliach. Toto dedičstvo takmer dokonale zodpovedá pracovným záťažiam umelej inteligencie: veľké súbory (trénovacie shardy, parkety, tar-y webových dátových sád, kontrolné body), sekvenčné čítania, veľa paralelných čítačiek, tolerancia pre „pracovnú záťaž regeneruje dáta“.

Čo robí XFS, čo ext4 nie: alokačné skupiny — zväzok sa rozdelí na 4–32 nezávislých skupín, ktoré čítajú a zapisujú paralelne bez globálneho uzamknutia denníka, čo je presne to, čo potrebuje viacúčelový DataLoader; oneskorené a špekulatívne predbežné pridelenie takže veľké sekvenčné zápisy majú súvislé rozsahy; žiadny praktický limit veľkosti súboru (8 EB); a xfs_growfs pre spoľahlivé jednoriadkové rozšírenie po raste RAID.

Čo nerobí: žiadne natívne snímky, žiadne kontrolné súčty súborových dát (metadáta chránené CRC od roku 2014), žiadne zmenšovanie — iba zväčšovanie.

Rozumné mkfs.xfs pre 8× NVMe RAID0 odkladací zväzok, 64 KiB chunk:

# 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 najdôležitejšie. XFS na malých súboroch je prijateľný, ale nie je jeho silnou stránkou – pre stovky miliónov obrázkov <16 KB ich radšej prebaľte do súborových systémov webdataset / parquet / lmdb než do swapovacích súborových systémov (pozri nižšie).

ZFS – správna odpoveď, keď záleží na integrite, snímkach alebo kompresii

ZFS je súborový systém, správca zväzkov a softvérová RAID vrstva v jednom:

• Kontrolný súčet od konca do konca. Pri čítaní bola zistená bitová strata, ticho opravená s redundanciou. Pre 50 TB dátovú sadu pri spinningu počas dvoch rokov je to dôležité; pre prchavý NVMe scratch počas šiestich týždňov to nie je dôležité.
• Snímky a klony. Atómový, COW, efektívne zadarmo. Snapshot pred spustením, vytvorenie klonu, vrátenie zmien – pracovný postup ZFS existuje.
• Vstavaná kompresia. lz4 predvolené zapnuté; zstd pre lepšie pomery. V texte / JSON / parkete sa kompresia zvyčajne zvyšuje efektívna priepustnosť, pretože náklady na CPU sú nižšie ako ušetrené I/O operácie.
• ARC — vlastná vyrovnávacia pamäť na čítanie v pamäti RAM, oddelená od vyrovnávacej pamäte stránok systému Linux. Slávna strelná zbraň.
• Natívny RAID-Z — žiadny mdadm.

Čo to nerobí dobre pre AI: spotrebuje RAM (predvolená hodnota ARC je ~50 % systémovej pamäte – na serveri s 512 GB, ktorý má 256 GB, ju jadro zrazu nemá a trénovacie úlohy očakávajúce vyrovnávaciu pamäť stránok alebo obrovské stránky sú ukončené funkciou OOM; obmedzte hodnotu ARC); nie najrýchlejší pre surové sekvenčné čítania (dobre vyladený XFS na NVMe RAID0 prekonáva ZFS o 15–30 % – kontrolné súčty a COW stoja skutočné cykly); ignoruje O_DIRECT (všetky I/O operácie sú zámerne cez ARC – pre väčšinu pracovných záťaží postačujú, existuje však závažná nekompatibilita s úložiskom GPUDirect).

Ladenie ARC – jeden gombík, ktorý musíte nastaviť

Na novej inštalácii Ubuntu + ZFS na 512 GB zariadení si ZFS nárokuje 256 GB pre ARC. zfs_arc_max pri inštalácii, nie po prvom 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: uzavrite ARC na 10–20 % systémovej pamäte RAM na serveri s umelou inteligenciou. Klasické dimenzovanie „2 GiB základne + 1 GiB na TiB“ je určené pre úložné boxy; na serveri s umelou inteligenciou je väčšina pamäte RAM vyhradená pre váhy modelov, aktivácie a vyrovnávaciu pamäť stránok frameworku.

Rozumné rozloženie ZFS pre dátovú vrstvu servera AI

# 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 — ak sa to pri vytváraní poolu pokazí, nedá sa to opraviť bez zničenia poolu. recordsize=1M pre pracovné zaťaženie s veľkými súbormi (predvolených 128 KiB je príliš málo pre viacGB shardy). xattr=sa ukladá xattrs inline, výrazne rýchlejšie ako predvolená hodnota.

Btrfs – vo všeobecnosti sa vyhýbajte pre produkčnú umelú inteligenciu

Btrfs má rovnakú koncepčnú sadu funkcií ako ZFS – COW, snímky, kontrolné súčty, vstavaný RAID. Na papieri áno; v praxi ho neodporúčame na serveroch Kentino. RAID5/6 má známe chyby spôsobujúce stratu dát, ktoré samotný projekt označuje ako nepripravené na produkčné prostredie (RAID1/10 sú stabilné, režimy parity nie); výkon sa výrazne znižuje v dôsledku fragmentácie, ktorú vytvárajú pracovné zaťaženia AI (gradientné kontrolné body, vyrovnávacie pamäte); výkon snímok prudko klesá nad niekoľkými stovkami snímok, čo pracovný postup na experiment dosiahne v priebehu štvrťroka; a nástroje na replikáciu, monitorovanie a plánovanie čistenia sú menej vyspelé ako ZFS alebo XFS. Na notebooku je to v poriadku. Pre server s viacerými GPU a desiatkami TB trénovacích dát si vyberte XFS alebo ZFS.

Rozloženia RAID – s čím spárovať súborový systém

Na diskoch s kapacitou 16 TB a viac môže opätovná zostava jedného disku trvať 24 – 72 hodín a druhé zlyhanie na diskoch z tej istej dávky v tomto období nie je zanedbateľné. Jednoduchá parita už nie je bezpečnou predvolenou možnosťou. Používajte Z2/RAID6 alebo zrkadlá.

Malé súbory verzus veľké súbory

Otázka, ktorá ľudí chytá do pasce viac ako akákoľvek iná voľba súborového systému: Ako sa váš súborový systém správa s 50 miliónmi 4 KB obrázkov v adresárovom strome? Odpoveď pre každý súborový systém tu: zle.

Metadáta na súbor (inode, dentry, časové pečiatky, xattrs) majú veľkosť 200 – 500 bajtov bez ohľadu na veľkosť súboru – 50 miliónov malých súborov spáli 10 – 25 GB metadát predtým, ako uloží bajt pixelových dát. Vzorec otvorenia/čítania/zatvorenia viaza stranu metadát a zastaví workery DataLoader.

Oprava nie je v súborovom systéme. Neukladajte malé súbory ako súbory. Zabaliť do webdataset / tar / parquet / lmdb / hdf5 / safetensors a sekvenčne streamovať — PyTorch WebDataset a NVIDIA DALI to očakávajú. Súborový systém potom vidí malý počet veľkých súborov, v čom je každý súborový systém tu dobrý. Ak musíte udržiavať jednotlivé súbory vo veľkom meradle, ZFS s recordsize=16k a xattr=sa je najmenej zlá možnosť, ale skutočnou odpoveďou je prebaliť.

Priamy I/O, vyrovnávacia pamäť stránok a O_DIRECT

PyTorch sa pri opakovaných epochách dátových súborov spolieha na vyrovnávaciu pamäť stránok systému Linux – epoch 1 z disku, epoch 2..N z RAM. Niektoré pracovné zaťaženia používajú O_DIRECT obísť vyrovnávaciu pamäť pri veľkých čítaniach, kde sa dáta dotknú iba raz. Úložisko GPUDirect od spoločnosti NVIDIA ide ešte ďalej a využíva DMA priamo medzi NVMe a GPU.

ext4 a XFS rešpektujú O_DIRECT správne – zarovnaný priamy I/O, žiadna vyrovnávacia pamäť stránok. ZFS ignoruje O_DIRECT (všetky I/O operácie cez ARC, zámerne): pre väčšinu úloh v poriadku, existuje však závažná nekompatibilita s úložiskom GPUDirect. Zarovnanie je dôležité – vyrovnávacia pamäť a posun musia byť zarovnané s veľkosťou bloku zariadenia (zvyčajne 4 KB).

Ak plánujete použiť úložisko GPUDirect Storage na napájanie 8-GPU boxu s plnou šírkou pásma, /data Musí to byť XFS na NVMe. Ak neviete, čo je GPUDirect Storage a trénovanie je viazané na výpočtový výkon, ešte ho nepotrebujete.

Viaccestné NVMe

Dvojportový U.2 / E1.S NVMe je prezentovaný ako dve cesty PCIe. Ovládač NVMe pre Linux podporuje natívnu viaccestnú komunikáciu (nvme_core.multipath=Y, predvolené v moderných jadrách), čo umožňuje failover a vyvažovanie záťaže round-robin. Neviditeľný na vrstve súborového systému, ale dôležitý pre failover (bez neho zlyhanie cesty/HBA spôsobí zmiznutie disku a súborový systém prepadne) a šírku pásma (viaccestný 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

Pre spotrebiteľské M.2 NVMe (zostavy desktopovej triedy 5090) nie je viaccestné pripojenie relevantné – iba jedna cesta. Pre zostavy EPYC s 8 GPU a podnikovým U.2 / E1.S v dvojradičovej backplane ho nechajte zapnuté.

Réžia kontrolného súčtu

Na 64-jadrovom hostiteľovi EPYC sú náklady neviditeľné. Na 16-jadrovom Xeone pri trvalom zaťažení môže ZFS ukradnúť 5 – 10 % efektívneho CPU – či na tom záleží, závisí od toho, či je trénovanie viazané na CPU pri predspracovaní (často áno pre vizuálne systémy) alebo na GPU (často áno pre rozsiahle LLM).

Úprimné zarámovanie: ZFS zachytáva bitovú stratu, ktorú by ste si inak nikdy nevšimli, kým sa váš model netrénuje na jemne poškodených dátach. Pre dátovú sadu, ktorú ste budovali šesť mesiacov, sa 5 – 10 % oplatí. Pre prchavé dátové súbory, ktoré regenerujete týždenne, to nie je pravda.

NFS pre zdieľané súbory údajov medzi uzlami klastra

Keď máte viac ako jeden server, zaujímavé je, kde sa súbor údajov nachádza. Tri vzorce:

1. Skopírovať do každého uzla. Jednoduché, plytvanie kapacitou. Fungujúce pre <1 TB a ≤4 uzly.
2. NFS z vyhradeného úložného servera. Jedna kanonická kópia. Sieť je úzkym hrdlom – minimálne 25 GbE, 100 GbE pre trénovanie viacerých uzlov.
3. Paralelný súborový systém (BeeGFS, Lustre, WekaFS). Väčší zdvih, váhy presahujú miesto, kde NFS prepadá.

Pre 1–4 uzly je NFS správny. Server: XFS na RAID10 NVMe, exportovaný cez NFSv4. Klient: pripojiť pomocou nconnect=8 paralelizovať medzi TCP pripojeniami.

# 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 cez 100 GbE s nconnect=8 poskytuje trvalú rýchlosť 8–10 GB/s – dosť pre 16 GPU pri typickom videní alebo tréningu LLM. Okrem toho BeeGFS / Lustre – téma na iný článok.

Kompletný príklad: 8-GPU 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

Priepustnosť surového NVMe tam, kde ju potrebujete, redundancia tam, kde sú dáta nenahraditeľné, komprimované hromadné spracovanie kontrolných súčtov pre všetko ostatné.

---

Toto je súčasť Kentino Wiki, referenčnej série o výpočtoch, úložiskách a systémoch, ktoré ich spájajú s umelou inteligenciou. Komentáre a opravy sú vítané na info@kentino.com.