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.
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.
Měl jsem silent corruption zachycenou scrubem na 12-diskovém MD RAID6 s XFS. A možná i několik nezachycených, to XFS se nakonec rozpadlo. RAID nedělá kontrolní součty, pouze parity, a silent corruption sice při scrubu najde a opraví, ale do té doby ten blok mohl někdo přečíst (při tom se parity nekontrolují) a vadný zapsat zpátky, parity pak budou sedět a silent corruption už to nedetekuje.
Kdyz pominu zfs ktery je problem vedle problemu, tak prave btrfs nad mdraidem je snad vubec to nejhorsi, co kdo kde muze mit.
BTW: Ty nevis jak funguje klascickej raid ze? Ten totiz nepozna a ani poznat nemuze kterej z N disku je vadnej, pokud nejde dokopru uplne a ani nic nereportuje ve SMARTu. Tak maximalne muze poznat, ze je vadny dany pole.
A specielne u mdraidu je jakakoli detekce toho spravnyho disku naprosto k smichu ...
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...
A uz se da vytvorit virtualni zarizeni reprezentujci pole (jako u MD) a obejit tim bug kdy moutovane zarizeni v poli neni dostupne ? Nebo se stale stava ze kdyz vytahnu/umre z RAID1 disk ktery se zrovna pouziva pro mount pole tak selze boot ? Popripadne bude vse vypadat podivne a budu mit fantom drive v OS kdyz jej vytahnu za behu ? Nebo je to nejak jinak resene ? Protoze tohle byl u RAID s btrfs kdyz jsem jej testoval epic fail.
Radeji jsem sveril sva data EXT4 a MD...
No jasne ze se pouziva UUID ale to nic neresi, me jde o to co se stane kdyz napr tomu disku jehoz UUID pouzivam pro mount / odejde elektronika ? pak disk proste zmizi a ja NENABOOTUJU protoze v tu chvili vlastne neexistuje cele pole protoze btrfs prinasi tu "uzasnou super vyhodu" kde staci mountnout libovolny disk z pole a pole se sestavi a pripoji...
Priklad: Ja tu mam RAID 1 z 4x2TiB disku:
Disk 1 UUID: aaa-aaa
Disk 2 UUID: bbb-bbb
Disk 3 UUID: ccc-ccc
Disk 4 UUID: ddd-ddd
Vytvorim na nich RAID 1 diky BTRFS
Disk 1 dam dle UUID (aaa-aaa) do fstab moutnu jako /home:
UUID=aaa-aaa /home btrfs rw,relatime,data=ordered 0 2
Restnu a vsechno pojede super truper...
Test 1: A pak vyrvu disk aaa-aaa z diskoveho pole za behu OS a vse zacne vypadat podivne! Vyzkousejte si to... disk zmizi i s UUID, moutpoint existuje a funguje ale OS neni schopen mi rict kam vede -> fail
Test 2: Vyrvu disk aaa-aaa za vypnuteho stavu (disky casto chcipaji pri rebootech) no a hadejte co se stane... OFC selze mount toho disku protoze neexistuje a je po bootu! :-D Aby clovek nabootoval tak musi vratit aaa-aaa do diskoveho pole protoze UUID a nebo nejakym zpusobem zmenit UUID ve fstab na jiny disk v poli
No proste uzasne navrzene btrfs muze jit s RAID do haje dokud tohle nejak nevyresi...
Tak to ani omylem, UUID kazdeho oddilu bylo uplne jine... proto se taky ptam, zda li je to opravene nebo ne testoval jsem to tak pred 2 mesici na aktualnim ubuntu.
Kdyz jsem odpojil jeden disk z diskoveho pole tak jsem skoncil na tom ze UUID nelze najit pri bootu a funkcni RAID 1 to byl.
Takze mkfs.btrfs -m raid1 -d raid1 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sde1 proste failnul zmenit UUID ? nebo to mam menit ja rucne ? Jel jsem podle https://btrfs.wiki.kernel.org/index.php/UseCases ... nikde zadnej notice nic
Ale uz ten fail konecne zacina davat smysl... (a cely reseni toho RAID mountu) tak se k tomu jeste vratim na aktualnim archu, alespon ted vim jak to pripadne vyresit protoze tehdy google nebyl nijak napomocen, jen jsem nasel lidi co meli stejny problem a jedina rada byla pouzit /dev nazvy a doufat ze se na misto puvodniho disku napasuje jiny disk z pole :-D Tak to me tehdy trochu nakrklo
Pro UUID oddílů se používá PARTUUID=
, pro UUID filesystému UUID=
. Zatím jsem neviděl distribuci, která by používala to první, protože UUID oddílů vyžadují GPT a to stále není výchozí (na MBR nemají oddíly UUID). S UUID=
boot funguje, i když vytáhnu první disk, protože je na všech discích stejný.
Tento vikend som sa s tym akurat hral. Ked vytvoris mirror na btrfs, dostanes pseudo UUID ktore zastresuje ten mirror a vsetky disky v nom. Dokonca to mozes spravit tak, ze spravis jeden btrfs disk, nahras nan data a potom pridas dalsi a nechas ich vybalansovat. Ked som vyrval jeden disk, tak to v pohode nabootovalo. Nasledne toto UUID pouzijes v fstab:
[root@anduril mirror]# btrfs filesystem show
Label: 'Mirror' uuid: e8cc237c-38fe-4f72-bebe-784224243cba
Total devices 2 FS bytes used 1.56TiB
devid 1 size 1.82TiB used 1.56TiB path /dev/sdb
devid 2 size 1.82TiB used 1.56TiB path /dev/sdd
Label: 'NonRaid' uuid: 570e554a-44db-4f89-a790-4b2fa5dbe52e
Total devices 1 FS bytes used 1.11GiB
devid 1 size 1.82TiB used 5.02GiB path /dev/sdc
[root@anduril mirror]# cat /etc/fstab
UUID=e8cc237c-38fe-4f72-bebe-784224243cba /mnt/mirror btrfs defaults 0 0
UUID=570e554a-44db-4f89-a790-4b2fa5dbe52e /mnt/nonraid0 btrfs defaults 0 0
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.
Btrfs to otestuje automaticky ve chvíli, kdy se poškozený soubor pokusíte přečíst. Vzhledem k tomu, že z mechanického disku se nikdy nečte, tak to automaticky ani nikdy neotestuje. Scrub se spouští ručně, abyste si mohl vybrat, kdy ho spustíte, jelikož snižuje výkon. Úplně stejně se spouští scrub na MD nebo ZFS. Pokud je vám jedno kdy, strčte ho do cron.weekly a bude se „sám spouštět sem tam na pozadí“.
Protože při kontrole filesystému je potřeba ten filesystém odpojit. Kdyby se filesystém sám od sebe odpojoval a kontroloval a znemožňoval uživateli práci, tak by z toho uživatel moc nadšený nebyl.
Ostatně ext2 se sám od sebe při startu kontroloval po určitém počtu připojení, a působilo to probémy - když zapneš počítač a půl hodiny nemůžeš pracovat, protože se to samo rozhodlo, že se to musí zkontrolovat.
Pozor, minimálně na btrfs (na ZFS nevím) není scrub kontrola FS v tom smyslu, jako ji provádí třeba e2fsck - při scrubu se pouze zkontrolují kontrolní součty, ale už se třeba neověřuje, že je to validní B strom (že jsou všechna data dosažitelná, že pointry nevedou někam dopryč, že tam není cyklus…).
Bohužel se mi to stalo, a nejsem sám.
Bug v SW, vadná RAM? Je to notebook (bez ECC), ale memtest86 nic nenašel. Teoreticky třeba má paměť při uspání pomalejší refresh nebo při převážení špatný kontakt… kdo ví. Bohužel mi přijde, že čím složitější FS, tím horší následky taková chyba má.
Pouzivame ZFS pro cold-storage videi na vice nez 60 PB dat, ZFS casto na chybu disku prijde mnohem drive nez smart. Uz ho mame pres ZFS na freebsd nebo zfs on linux nasazeny dele nez 8 let a jeste jsme nikdy neprisli o zadna data. Rychlost pole resime pres SSD na SATA nebo SSD na nvme.
S BTRFS jsme prisli o data, nastesti jenom pri testech, takze jsme to nikdy nenasadili, mame totiz tu smulu ze pouzivame RAID-6 konfigurace.
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.
No...
http://open-zfs.org/wiki/Hardware#Controllers: Hardware RAID controllers should not be used with ZFS. A vycet duvodu...
No, tak si tam pozorně přečtěte ty důvody, a jsou to ty, co jsem psal. ZFS bez RAID je lépe ovladatelné z jednoho místa (ZFS nástroje), máte lepší kontrolu nad tím, co se děje až na úroveň disku. Typický usecase: FreeNAS. Pokud víte, co děláte, a má to racionální důvod,není HW RAID na překážku.
Z Vašeho postu to vyznělo tak, jako kdyby mě být ZFS s HW RAIDEM nefunkční, či nespolehlivý.
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.