Vlákno názorů k článku
Btrfs zrychluje čtení ze SSD v RAID1/10 od Czlovek - Spíš jak to vypadá s btrfs RAID5/6? Dočkáme...

naposledy byla ve 4.12 opravena velká chyba, i tak se zatím nedoporučuje používat v ostrém provozu
https://www.root.cz/zpravicky/btrfs-raid-5-6-se-docka-oprav-v-jadre-4-12-stale-vsak-radeji-nepouzivat/

Btrfs úplně nesleduju, používám ZFS. Mám zejména pocit, že vývoj není úplně pevně vedený (směřovaný) ke stabilitě. Chybí mi milníky, kdy mohu očekávat, že tento FS bude možný použít produkci. Skoro to vypadá, že vývoj je vedený metodou pokus-omyl. Standardní by bylo uvolnit filesystem s méně funkcemi, ale stabilní. Pak teprve přidávat funkce, které budou bezpečně otestované. Takto to vypadá, že nikdo vlastně neví, co btrfs dělá, nebo udělat může. Velká škoda.

Je to možné, opravdu btrfs nesleduji, komentuji jen, jak na mě zprávy o btrfs působí.

Netgear si chvíli hrál se ZFS, ale nakonec to asi zapíchl. Takže oba větší výrobci (Synology a Netgear) celkem profi zařízení používají kombinaci mdraid a btrfs (pochopitelně bez RAID).

Vůbec se jim nedivím, kombinuje to všechny vyhody dohromady (vysoká stabilita a moderní funkce) ZFS je v mnoha ohledech problematické. Respektive od ZFS zdrhnul snad každý kdo to chtěl opravdu používat. Ostatní si pořád tak nějak hrajou, nebo je jim ukradené jaký to má výkon. Scénář pokaždé stejný (velké nadšení, testování a tichý odchod) - jako funguje to, ALE je to fakt strašně neefektivní.
Běží vám to pomalu, máte alespoň 128GB RAM? Eee tak tam hoďte SSD jako cache - sorry jako :-) fakt vtipné.

Hlavní deviza "silent-corruption-free" je diskutabilní, jen si to vemte disk dělá kontrolní součty, řadič dělá kontrolní součty, RAID taky a pokud má víc jak jednu paritu naprosto OK a ECC paměti taky kontrolují svůj stav.
To se už může stát cokoliv někde za tím. Zažil někdo v RAID6 třeba silent-corruption?

ZFS je super na papíře, ale v reálu už to není takový odvaz, snad ta replikace to je fajn.

Někdy mi připadá, že "silent corruption-free" znamená spíš "silent corruption, free!" ;-) Těch problémů se ZFS je celá řada. Kromě těch, které jste zmínil, je dle mého názoru jedním z největších to, že ZFS nemá podporu xattr. Sice se tváří, že ji má, ale ve skutečnosti je každý atribut samostatný soubor ve skrytém adresáři. Každý přístup k atributu tak vyžaduje kompletní vyhledání cesty. U věcí, jako je SELinux, kde se kontrolují nebo mění atributy při jakékoli operaci se soubory, to má naprosto děsivý dopad na celkový výkon... a to ještě není to nejhorší unikum. Tím je to, že každé nastavení atributu na ZFS je tedy ve skutečnosti obyčejný zápis do souboru, a to znamená, že - kromě pomalosti - není atomické! Zvlášť u bezpečnostních aplikací, jako právě SELinux, to má velmi "zajímavé" důsledky.

Je sice pravda, že minimálně na Linuxu se ZFS snaží tohle řešit volbou attr=sa, která zapne podporu opravdických atributů, ale je to nekompatibilní změna a používat ji znamená odsoudit se k používání něčeho, co už není oficiální podporovaný ZFS.

Neméně "pozoruhodný" je multithreading. Původní verze ZFS pro Solaris řeší multithreading pomocí atomických instrukcí CPU, ke kterým vnitřní API Solarisu dává přímý přístup z C kódu. U portu na FreeBSD je nahradili zamykáním, a je tomu tak i na Linuxu (přestože ten - nevím jak FreeBSD - má ekvivalentní atomické API běžně používané všude jinde v kernelu). Takže až se zase někdo bude divit, proč je ZFS tak pomalý a tolik prohání CPU, tak tohle je jeden z hlavních důvodů.

Samozřejmě kapitolou sám o sobě je algoritmický návrh, který jako jediný moderní FS nepoužívá extentovou alokaci, místo toho má přímo referencované bloky jako starý Unix a možnost je za jistých okolností shlukovat do metabloků, o čemž se sám jistý vývojař ZFS vyjádřil, že to je paskvil...