Názory k článku
Btrfs zrychluje čtení ze SSD v RAID1/10

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...

Přesně tímto způsobem se mi před 5 dny rozpadlo Synology (DS218+), naštěstí zatím bez dat. Zrovna jako na potvoru první disk v "poli" vyhnil, z druhého to nenaběhlo a rozsynchronizovalo se to.

Asi nechápu, scrub umí. Spíš jde o to, že pokud máte stejná data na SSD a HDD a bude se číst jen z rychlejšího SSD, můžou data na HDD vyhnít. Tedy je dobré pouštět scrub.

Filesystem si má zachovávat určitou vícefunkčnost a neutralitu. O toto by se měl starat OS - resp. v případě Linuxu ekosystém OS a distribuce kolem něj. Samotnému btrfs bych to tolik ani nevyčítal, byť důsledky jsou opravdu k zešílení. Se zavaděči, mirrorem (jakéhokoliv typu), ..., byl vždy trochu problém, to není jen vinou btrfs.

Linux si trochu nešťastně zvykl zavádět přes initrd - to vzniklo před dávnými lety, kdy se image kernelu musela vejít do (tuším 4MB) a zbytek musel být v modulech. Myslím, že initrd dělá nepříjemný mezikus mezi bootloaderem a spuštěním initu (or whatever). Díky tomu, co distribuce, to odlišná procedura zavádění systému. A díky tomu musí být i filesystem dostatečně univerzální.

Myslím, že nejen Windows, ale i FreeBSD mají z pohledu uživatele startovací proceduru daleko přímější, jednodušší a instalovanou jedním vrzem. U Linuxu to bude holt chvíli trvat, než se všichni shodnou na nějakém společném řešení.

Co bych btrfs naopak maličko vyčítal je, že implementuje funkce z low end poptávky a mám trochu starost, jestli z něj nakonec nebude tak trochu kočkopes. Nejde, podle mě, udržovat vývoj filesystemu, který má jak enterprise vlastnosti, tak řeší kdejakou nestandardní hardwarovou situaci. Kombinace HDD a SSD v jednom raidu je podle mě přesně taková vlastnost, bez které by se enterprise filesystem lehce obešel.

při scrubu se fs neodpojuje, ale práci samozřejmě zpomalí

ZFS je za běhu.

ZFS je za běhu.

SMART selhává v signalizaci dost často, není to vůbec všespásná technologie.
Mnohé řadiče, hlavně spotřební třída, pak zablokují celé I/O ve chvíli, kdy začne jediný disk poskakovat (relokuje vadné sektory apod.).

Myslím, že "souboj" na tomto poli je daný tím, že jak btrfs, tak ZFS se snaží obsloužit jak enterprise třídu, tak i entry level. Btrfs je zajímavější po českého hobbybastlera, protože ZFS má daleko větší HW nároky (a to se samo o sobě vylučuje s hobbybastlerstvím).

Výslekdem pak je, že kdekdo, kdo má ztěží 16 GB RAM (a mnohdy méně) a integrovaný SATA řadič, pomlouvá ZFS pro nepoužitelnost. Naopak btrfs se může jevit jako sympatický systém, který stačí jen "trochu dotáhnout".

Uživatelé z enterprise kategorie naopak ZFS používají poměrně bez problémů a btrfs, díky "drobným nevýhodám" jako je občasná inkonzistence, či částečná ztráta dat, vůbec nemohou zvažovat k nasazení.

Proč by neměl jít použít na polích spolehlivě? Pokud potřebujete pokročilou práci se ZFS pools a flexibilitu, kterou nabízí, pak disky exportujete jako JBOD. Pokud ale víte, že pole Vám vyhovuje tak jak je, není nejmenší problém použít pole.

Systémy typu FreeNAS preferují JBOD / nepoužívat HW RAID, protože by v tom množství výrobců nebyli schopni monitorovat zdraví disků a polí (usupportovali by se), ale tam, kde si tvoříte vlastní řešení, nepředstavuje to vůbec překážku.

Je to složitější. V dokumentaci k ZFS se vychází z premisy, že většina HW řadičů střední třídy nemá žádný výkonnostní přínos. Tím jsou myšlené všechny základní raidy na deskách, případně ještě dovršené připojením na backplane s expanderem. V takovém případě je určitě stejně dobré, nebo i lepší, aby disky byly JBOD a jak RAM cache, tak SSD cache dělalo ZFS.

V případě drahých RAID řadičů, s 1-2GB cahce, vlastní SSD cache atd., může být situace jiná. Tam pak už je pro ZFS argumentem jen to, že disky se dají přenést do jiného stroje přes libovolný řadič, že zákazník získá hardwarovou nezávislost. Ne vždy je to ale ohled, který se řeší.

Osobně využívám většinou řadiče s exportem JBOD, ale asi ve dvou, třech případech mám ZFS nad HW raidem a funguje to dobře a lépe. Nevýhody, které to má, si uvědomuji, a jsou kompenzovány jinými způsoby.