Dotaz: sdílené disky jaký raid.

[chinook]

Zdravím, mám tři disky WD Ultrastar DC HC320 8TB asi by nebyl problém koupit 4. Přemýšlím jaký udělat raid. Chci udělat RAID1, ale ze dvou disků a jeden jako hot spare nebo rovnou použít tři? Jaký filesystém? EXT4 a SW raid? Nebo použít HW raid? Chci použít SW raid. Server je starší, kdyby odešel lehce přehodím disky jinam a jedu.

děkuji za rady

---

---

Odpovědi

[Andrej]

Stálo by za úvahu trochu vyhledávat na ABCLinuxu. Tohle už se tady řešilo minimálně dvacetkrát za posledních cca 5 let.

Chci udělat RAID1, ale ze dvou disků a jeden jako hot spare nebo rovnou použít tři?

Hot spare je v tak malém systému všeho všudy nefunkční nesmysl, disk k nepotřebě, vyplýtvaná kapacita. Nejlepší je mít 3 disky a na nich 2 repliky dat, což dá solidní 3/2 kapacity jednoho disku. Tedy, pokud je z nějakého důvodu požadavkem vyhnout se paritnímu RAIDu, který by dovedl se stejným hardwarem a stejnou redundancí poskytnout dvojnásobek kapacity jednoho disku.

Jaký filesystém? EXT4 a SW raid?

Ach jo… Už zase tohle… Ne. Neexistuje žádný SW RAID na Ext4 nebo s Ext4. Nic takového prostě neexistuje. (Opět doporučuji hledat ve zdejší historii.)

Nebo použít HW raid?

Jen to ne.

Zaprvé, je to recept na ztrátu dat. Něco se stane s proprietárním řadičem a jeho proprietárním formátem metadat a všechno je fuč, bez šance na obnovu na jiném systému.

Zadruhé, většina takzvaně hardwarových takzvaných RAIDů je ve skutečnosti AID bez R, který jen čeká jako žralok s otevřenou hubou, kdy bude moci sežrat data.

Chci použít SW raid.

Dobrý nápad, ale pozor na věc:

• Skutečný RAID (kterému nechybí R) je pouze a jedině ten, který je vestavěný do souborového systému.
• Souborové systémy se skutečným RAIDem jsou například Btrfs nebo ZFS. Různé zoufalé abstrakční vrstvy, které se v uplynulých desetiletích marně snažily doplnit RAID „pod“ zastaralé souborové systémy, jsou všechny pouze AID, jedna jako druhá, se zásadními problémy kolem integrity dat.

[Jendа]

Souborové systémy se skutečným RAIDem jsou například Btrfs nebo ZFS.

Ano, btrfs má sice skutečný RAID, a tazateli by se mohlo líbit, že do toho může snadno přidat ty 3 disky a mít 1.5násobek kapacity, a taky snapshoty, kompresi a další super funkce, ale naprostý fail je, že btrfs (a asi ani ZFS, ale to nepoužívám) nemá (použitelný) fsck. Takže až se mu to rozbije tak je nahranej (doporučovaný a asi jediný použitelný postup je odlejt data pryč, vytvořit FS znova a nalejt data zpátky).

[Andrej]

…ale naprostý fail je, že btrfs (a asi ani ZFS, ale to nepoužívám) nemá (použitelný) fsck…

Tohle je naprostý nesmysl a naprosté nepochopení, k čemu u starých a špatných souborových systému (ne)sloužil fsck.

Takže až se mu to rozbije tak je nahranej…

S čím tady srovnáváme? Co je baseline? S Ext4 bude tahle „nahranost“ mnohem horší a pravděpodobnost rozbití mnohem vyšší. Takže, co přesně je ten svatý grál, který funguje lépe než Btrfs a ZFS? Yeti už byl viděn, ale ta zázračná technologie dosud ne.

[Jendа]

Tohle je naprostý nesmysl a naprosté nepochopení, k čemu u starých a špatných souborových systému (ne)sloužil fsck.

Já si myslím, že fsck slouží ke zjištění a opravě (potenciálně se ztrátou dotčených souborů, které si obnovíš ze zálohy) souborového systému, u kterého se poškodily invarianty datových struktur (že listy stromů a pointery hashtables neukazují na nesmyslná místa, že jsou všechny bloky označené jako alokované dostupné, a já nevím co vlastně FS dělá). Koneckonců teď jsem si otevřel manuál k btrfs fsck a tam se píše přesně tohle:

The filesystem checker is used to verify structural integrity of a filesystem and attempt to repair it if requested. The structural integrity check verifies if internal filesystem objects or data structures satisfy the constraints, point to the right objects or are correctly connected together. There are several cross checks that can detect wrong reference counts of shared extents, backreferences, missing extents of inodes, directory and inode connectivity etc.

No a problém je v tom, že se na té stejné stránce píše taky

Warning

Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. Eg. some other software or hardware bugs can fatally damage a volume.

Jako možná už to funguje, už jsem to nějakou dobu nezkoušel. Ale s těmi varováními to nepůsobí moc důvěryhodně. Samozřejmě je možné, že autoři btrfs mají jinou hranici toho, před čím považují za nutné varovat, a ve skutečnosti to funguje stejně dobře jako fsck klasických fs.

A kdy třeba se takový fsck může použít? Třeba když máš filesystém, který projde scrubem, a přitom se na něm děje tohle:

root@ferda:~/psql_bonanza_backup# ls pg_stat_tmp/
db_0.stat  db_0.stat  db_0.stat  db_0.stat    global.stat  global.stat	global.stat  global.stat  global.tmp  global.tmp  global.tmp  global.tmp
db_0.stat  db_0.stat  db_0.stat  global.stat  global.stat  global.stat	global.stat  global.tmp   global.tmp  global.tmp  global.tmp
root@ferda:~/psql_bonanza_backup# ls -l pg_stat_tmp/
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
ls: cannot access 'pg_stat_tmp/db_0.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.stat': No such file or directory
ls: cannot access 'pg_stat_tmp/global.tmp': No such file or directory
total 0
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? db_0.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.stat
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp
-????????? ? ? ? ?            ? global.tmp

Jak to mohlo vzniknout? Třeba softwarovým bugem (race condition…), hardwarovým bugem disku (HW kecá co už zapsal a co ještě ne a přehazuje pořadí zápisů) nebo hardwarovým bugem paměti či procesoru (stroj nemá ECC, na stroji se přehřívá CPU a dělá chyby).

S čím tady srovnáváme? Co je baseline? Takže, co přesně je ten svatý grál, který funguje lépe než Btrfs a ZFS?

Baseline je, že na ext4 pustím fsck, a ono se to ve většině případů dostane do konzistentního stavu. Možná to přijde o pár souborů, ty obnovím ze zálohy. Pokud to bylo fakt hodně špatný, tak pak je samozřejmě lepší FS zrušit a vytvořit znova.

S Ext4 bude tahle „nahranost“ mnohem horší a pravděpodobnost rozbití mnohem vyšší.

Nebo nebude, protože je jednodušší a tak tam je méně věcí co se můžou rozbít (to není výtka na btrfs, pokud chceš mít všechny ty funkce, co btrfs poskytuje, tak to prostě složité být musí). Nebo nebude protože je víc otestovaný. A nebo samozřejmě bude, pokud je tvým problémem zrovna ten typ selhání disku který zachytí btrfs checksum.

[Max]

Jen ze zajímavosti, ta chyba nastala na jakém kernelu / verzi btrfs / čase? A byla použita redundance (raid1 apod)?
Nechci to nějak pitvat, jen mě zajímá, za jakého druhu provozu to nastalo.
Díky
Zdar Max

[Jendа]

Jen ze zajímavosti, ta chyba nastala na jakém kernelu / verzi btrfs / čase?

Celkem nedávno, byl to Buster s kernelem 5.6 z backports, a pak se to upgradovalo na Bullseye s distribučním 5.10, a někdy tou dobou se to stalo. Je to Ryzen 5 3600, desktopová deska, desktopová nvidia a lidi na tom dělají machine learning a byly tam různé problémy - myslím že to vytuhávalo (nebo to byl vedlejší stroj?), několikrát jsme tomu natvrdo vyhodili elektřinu, procesor ukazoval nějak vysokou teplotu ale možná to byl bug ve čtení senzorů, dělají na tom junioři a už jsme měli případ že se jim něco zacyklilo a postgres asi za měsíc zapsala 100TB (většina povoleného TBW disku) než jsem si toho všiml a dokopal je to opravit, atd. Takže ano, technicky je to dost příšerný počítač a věřím že to klidně mohlo být způsobené HW chybou RAM/CPU nebo tomu třeba nvidia driver corruptnul nějaké datové struktury, ale tazatel taky neříká že ten jeho NAS je nějaký super spolehlivý server. Redundance použita nebyla, ale vzhledem k tomu, že scrub prochází, by to asi nepomohlo.

[Andrej]

Baseline je, že na ext4 pustím fsck, a ono se to ve většině případů dostane do konzistentního stavu.

Jak? Jak může bez atomicky udržovaných checksumů dat poznat konzistentní stav? Tenhle princip fungování fsck je jakýsi sen, nikoliv realita.

Dobře, dejme tomu, zkusí asi obnovit konzistentní stav (většinou) checksumovaných metadat; čert vem data. To je ovšem poněkud nedostatečné.

Jak to mohlo vzniknout?

Tohle jsem už zažil. Nevím, jak to vzniklo, ale vzpomínám si, za jakých okolností.

Před lety jsem měl SSD s firmwarem nekompatibilním s Linuxem, který dělal cosi neobvyklého při uspání. Systém následně vypadal jako hrad Trosky. Po cca 20+ násilných restartech z nevysvětlitelného stavu systému se tohle stalo — v nějakém adresáři bylo pár položek se stejným názvem.

Opravil to tenkrát (tolik obávaný) btrfs check --repair, žádný problém. Jinak souhlasím, že taková věc by neměla projít scrubem bez varování (a bohužel prošla).

Nechápu ovšem, oč lépe by stejnou situaci ustál Ext4 a jakou by mi dal záruku, že jde opravdu jen o poškození metadat v nějakém adresáři a že nejsou poničené moje datové bloky.

Pokud selhává hardware (který ve „spotřebitelském sektoru“ už desetiletí a půl nezaručuje, že „bariéra je opravdu bariéra“), nepopere se s tím korektně žádný souborový systém.

Aktualizace firmwaru od SSD tohle vyřešila, nepříliš překvapivě.

Takže se znova ptám: Kde je ten zázračný baseline, se kterým Btrfs srovnáváme?

…and then only after having accepted that no fsck successfully repair all types of filesystem corruption…

A tohle^^^ platí pro Ext4 mnohem víc než pro Btrfs, že jo.

Nebo nebude protože je víc otestovaný.

Takže ty statisíce strojů Facebooku, které mají už snad desetiletí Btrfs RAID1, nejsou dostatečný test? Stále nechápu, co je baseline pro srovnání.

A nebo samozřejmě bude, pokud je tvým problémem zrovna ten typ selhání disku který zachytí btrfs checksum.

Dejme tomu, že mým problémem bude přepsání (omylem, lidský faktor atd.) jednoho ze tří disků v RAID1 konfiguraci nulami.

Rádoby-abstraktní AID s Ext4 následkem toho kontaminuje a/nebo zničí všechna moje data. Chvíli mi navíc může vracet náhodné, nulovými bloky prokládané nesmysly, než se konečně položí.

ZFS a Btrfs i takovou mezní situaci ustojí a nebudou mi vracet poničená data. Jen v dmesg bude dost dusno.

[Jendа]

Jak může bez atomicky udržovaných checksumů dat poznat konzistentní stav?

Konzistentní stav se pozná tak, že jsou právě všechny obsazené bloky dosažitelné, všechny soubory mají čitelná metadata (jak bylo ukázáno), nejsou tam hardlinky na adresáře atd. Samozřejmě to není konzistentní stav z hlediska aplikací a toho že soubor co jsi někam uložil a poté úspěšně proběhl fsync tam taky najdeš. Ale většinou je dost jasně vidět kterých souborů se to týká (právě z těch metadat) a tedy co je potřeba obnovovat a jestli je to problém.

Jinak souhlasím, že taková věc by neměla projít scrubem bez varování (a bohužel prošla).

Protože scrub jenom zaručuje, že bloky, co jsme přečetli, jsou bloky, co jsme (někdy) před tím zapsali. V žádném případě nezaručuje, že obsah těch bloků je smysluplný, a bohužel ani příliš nezaručuje, že bloky jdou chronologicky. Bohužel se tohle málo ví, a leckdo říká "haha mám scrub, nepotřebuju fsck!", a je potřeba upozorňovat na to, že to tak není. A pak má na FS chyby, o kterých se nemá jak dozvědět, a narazí na ně až v okamžiku, kdy se třeba pokusí zapsat do nějakého souboru. (btrfs je dobrej že alespoň má nějaký fsck, ZSF pokud vím nemá vůbec nic)

Nechápu ovšem, oč lépe by stejnou situaci ustál Ext4 a jakou by mi dal záruku, že jde opravdu jen o poškození metadat v nějakém adresáři a že nejsou poničené moje datové bloky.

Nedal by ti takovou záruku (btrfs ti ji taky nedává, stejně jako se poškodily bloky s metadaty se mohly poškodit i bloky s daty), ale pro opravu bys nemusel použít nástroj, který má na začátku dokumentace tučné varování, že ho nemáš používat.

A tohle^^^ platí pro Ext4 mnohem víc než pro Btrfs, že jo.

Nevím proč by to mělo platit mnohem víc, napsal jsem nějaké důvody hovořící pro btrfs a nějaké pro ext4 a jejich přesné vyhodnocení by vyžadovalo v podstatě neproveditelnou analýzu konkrétního nasazení.

[Andrej]

Zkrátka, Btrfs a ZFS dávají nesrovnatelně silnější záruky konzistentnosti dat než Ext4 béčko bez checksumů. To je celé. Takhle jednoduché to je.

Pročež tazateli (jako obvykle) doporučuji: Vyhni se Ext4 — béčku spoléhajícímu na zázraky — a použij takový souborový systém, který chápe, jak tenhle vesmír funguje, tedy Btrfs nebo ZFS.

Že prý ZFS nemá „fsck“ — no a? Kdo takový nesmysl na ZFS kdy potřeboval? No nehlaste se všichni.

[k3dAR]

nebo je to jeste jednodusi, z praxe po X let sem s (mdadm/lvm, luks/lvm)/ext4 neprisel o data, z 2 pokusu s BTRFS sem prisel o data 2x

[Andrej]

Máš to rozbité.

Ten béčkový AID jsi testoval na přesně stejném hardwaru jako Btrfs? Nebo jsi (jako spousta jiných známých mudrců) dával Btrfs na vyřazený šrot, zatímco AID z nějakého důvodu dostal nový hardware? Režim povozu byl taky přesně stejný? Jenom se ptám, čisté pro úplnost.

(Nebo jsi na AID taky ztratil data, jenom jsi o tom (kvůli absenci checnsumů) nevěděl?)

No a pak tu ještě kdysi byla ta sorta lidí, která zkoušela Btrfs na 5 let zastaralé sračce typu Debi(l)an a následně v roce 2014 říkala: „Šmarja! Jak to, že tam mám bugy z roku 2009???“ No … ehm … byly tam. Co se dá dělat…

Pořád lepší než rozesraný Ext4 každé tři roky, jak velí neochvějná tradice. Nemluvě o silent data corruption, která pracuje průběžně a 3 roky nečeká.

[Rocky]

A jaká je ta správná, moderní a stabilní distribuce?

[Andrej]

Má kernel ne starší než měsíc.

[k3dAR]

to sedi

k3dar@t430s:~$ lsb_release -d
Description:    Ubuntu 20.04.4 LTS

k3dar@t430s:~$ uname -vr
5.17.7-051707-generic #202205121146 SMP PREEMPT Thu May 12 13:20:51 UTC 2022

[trekker.dk]

Pořád lepší než rozesraný Ext4 každé tři roky, jak velí neochvějná tradice. Nemluvě o silent data corruption, která pracuje průběžně a 3 roky nečeká.

Máte to rozbité. Narozdíl od ostatních, kterým ty ext4 fungujou v tisícovkách bez výpadku a bez ztráty dat.

Vzhledem k tomu, že Andrej ext4 opovrhuje, bude mít rozbité nanejvýš tak btrfs.

Ale btrfs, když mu něco změní pod rukou na disku obsah uložených souborů, tak minimálně pozná, že se tak stalo a upozorní na to. Zatímco ext4 pozná leda tak kulové, takže zůstává v pohodě. A když to btrfs bude v nějakém raidu, tak ten obsah souboru dokonce i samo opraví, o čemž si ext4 může nechat zdát.

[PetebLazar]

Jak pozná btrfs, pokud něco změní škodlivě obsah souboru včetně všech souvisejících btrfs záznamů?

[Andrej]

Tohle jsou zase perly. No, stane se. Já ti to zkusím vysvětlit polopatě.

Jak pomůže bezpečnostní pás, když na stojící auto spadne vagón olova?

Inu, bezpečnostní pás v takové situaci nijak nepomůže. To ale ještě neznamená, že by bezpečnostní pás nebyl důležitý. Pomáhá totiž v mnoha jiných nebezpečných situacích.

Tak. Už?

Ještě polopatěji: Btrfs, ZFS a plně checksumované souborové systémy prospívají tím, že místo celé pravděpodobnosti poškození dat v bloku čelí uživatel jenom pravděpodobnosti poškození dat v bloku krát pravděpodobnost kolize checksumů. To druhé (součin) je nesrovnatelně menší než to první.

Pravděpodobnost současného poškození několika bloků tak, že to čirou náhodou bude vypadat jako platná data, je cosi z říše fantazie. Jasně, nulová není, ale…

Úmyslně změnit data na Btrfs a odpovídajícím způsobem upravit všechny datové struktury je postup (v konečném důsledku) nerozlišitelný od skutečného zápisu — použijme tedy zdravý rozum, Occamovu břitvu atd. atp.

[Andrej]

Ale hovno.

U Ext4 se nedá nijak poznat, jestli funguje bez ztráty dat.

[trekker.dk]

Samozřejmě, že se to dá poznat. Tím, že se ta data neztratí. Vám se možná ztráty dat dějí s vašimi experimentálními systémy tak pravidelně, že je taková událost pod vaši rozlišovací schopnost, ale jinde to běžné skutečně není.

[Jendа]

To ale asi půjde jenom pro některá nasazení, třeba object storage, kde máte u souboru metadata s checksumem a můžete ho při zápisu spočítat a při čtení zkontrolovat. U obecného použití FS to nepůjde.

[PetebLazar]

A co když bude Ext4 postaven nad dm-integrity device? Pak by to mohlo platit i pro obecné použití (detekci skryté chyby zajistí nižší vrstva).

[Jendа]

Že prý ZFS nemá „fsck“ — no a? Kdo takový nesmysl na ZFS kdy potřeboval?

WTF, vždyť o tom je celé vlákno. Dokolečka dokola: Jak teda FS bez fsck řeší detekci a opravu chyby struktury způsobené ať už SW (klidně můžeme připustit, že je driver FS bezchybný, ale kdokoli jiný v kernelu mu mohl přepsat kus dat) nebo HW bugem (RAM bit flip)?

[Peter Golis]

Detekciu chýb NextGEN FS rieši SCRUB, to je taký akoby FSCK ktorý skontroluje konzistenciu aj keď FS nemá príznak DIRTY. Obvykle to rieši aj s opravou, ak bol FS vytvorený s redundanciou.

[trekker.dk]

Takže ty statisíce strojů Facebooku, které mají už snad desetiletí Btrfs RAID1, nejsou dostatečný test?

Měl byste se řídit vlastní radou a hledat ve zdejší historii. Facebook skladuje zejména data, u kterých neposkytuje naprosto žádné záruky, že zítra budou tam, kam je uživatelé včera nahráli. Takže to není žádná metrika spolehlivosti souborového systému.

[Max]

Sazmozřejmě máš pravdu, ale zase na druhou stranu, když by se k těm datům pak někdo nedostal, měl bý facebook špatné PR. Takže i v jeho zájmu je, aby ty data šly dostat ven. A pak je tu také to, že jedna věc je technické řešení, druhá věc pak právní rovina, kdy je nejvýhodnější se od všeho distancovat :D.
Zdar Max

[Andrej]

Samozřejmě nemá pravdu. Jako obvykle.

[AraxoN]

Mirror z dvoch diskov, na tretí radšej robiť zálohu. Pretože RAID nie je záloha.

Ext4 je vyladený a preverený systém na univerzálne použitie. Nič ním asi nepokazíš.

Ak chceš raz prehodiť disky inam a pokračovať, HW RAID-u sa vyhni. Obecne HW RAID sa dal doporučiť len v prípade, že bol požadovaný špičkový výkon. Dnes v takom prípade je lepšie siahnuť po nejakom SSD disku typu Write Intensive/Performance (napr. Nytro 3xxx).

[Jendа]

Udělal bych RAID ze dvou disků a na třetí zálohoval. Ideálně s historií (snapshotama). Není to ideální (zálohovat do stejného počítače) ale výrazně lepší než nic (protože osobně potkávám mnohem častěji než selhání HW selhání lidského faktoru - omylem něco smažeš, případně selhání SW - a u RAIDu se ti taková chyba ihned zrcadlí a máš smůlu).

RAID samozřejmě softwarový.

[X]

Chybi dost podstatna informace k cemu to vlastne bude? Nehodlas z toho startovat server, ze ne?

[Jendа]

V čem by byl problém kdyby hodlal?

[X]

Netvrdim, ze je to problem, ale server na dvou 3.5 plotnovych diskach v mirroru? To se vracime tak do roku 2005..

[Andrej]

1) Mít hotspare je podle mě v tomto případě docela zbytečně drahá sranda.
2) Pokud zůstaneš u třech disků, použil bych btrfs v režimu data+metadata raid1
3) Pokud koupíš další disk, tak můžeš jít do mdadm raid10 + nějaký fs nad tím (dnes bych volil xfs, ext4 je opravdu už velký dinosaur a má nemálo problémů/nepříjemností), nebo btrfs radi1 pro data a tři kopie pro metadata (raid1c3).

Rozhodnutí je na tobě. btrfs ti dá možnost snapshotů a lepší kontrolu konzistence dat, ale zase horší výkon (protože režie CoW).
Já osobně jedu btrfs raid1 pro data a raid1c3 pro metadata.
Zdar Max

[czjaromir]

Ted jsem si udělal v pc raid na data a mám raid 5 btrfs. Na system mam ssd disk. Jestli je raid pomalejší nebo rychlejší mě netrápi. Jen doufám že nebudu přicházet o data. Ale zdá se že nějaký problémek tam bude taky. Jestli tam náhodou není problém s velikostí ukládaných souborů. Na tom btrfs.

[czjaromir]

Tak zase jsem měl ukvapený názor funguje skvěle.

[j]

Pocitam ze se tu zachvili objevi nejakej sejcek, kerej ti zacne vykladat, jak je R5 unstable, takze ho mam 10 let uplne vpohode.

Problem muze nastat (a to je neprekvapive uplne stejny u vsech FS) kdyz neco zapisujes, a v ten okamzik to vytrhnes z elektriky.

Proto se pouzivaj UPSky a u tech HW raidu i baterky na cache atd atd.

---

Dete s tim guuglem dopice!

[Max]

Delší dobu jsem u btrfs nad RAID5 přemýšlel, ale pak, když jsem zjistil, jak funguje RAID1 a RAID1C3, jsem do toho nešel. Neviděl jsem pak v RAID5 žádný přínos. A pořád nad ním navíc visí nějaké nevyřešené věci, které se v 99.99% případů nestanou, ale za nějakých konstelací mohou. Lidi to ale používají hafec let a žádný problém.
Zdar Max

[trekker.dk]

Cca rok zpátky jeden z hlavních vývojářů btrfs sám řekl, že RAID5 není úplně dobrej nápad. (Najdete někde na LWN.net, pokud vás zajímají detaily)

[Max]

Mají to i v dokumentaci. Ale jak už jsem napsal, lidi to provozují a nemají s tím problém. Každopádně mě nevyhovoval ten stav pomyšlení, že existuje nějaká 0,01% šance, že se to může rozsypat na základě známého problému, že tam nějaký stav není ošetřen apod.
A když člověk zjistí, jak funguje raid1 a jeho varianty, tak na raid5 zapomene.
Zdar Max

[Jendа]

Btrfs bude varovat při vytváření a konvertování RAID5/6

[Peter Golis]

Ten žurnál čo implementovali pre Raid 5/6 pred piatimi rokmi to nevyriešil? To je potom zaujímavá dilema prečo žurnál dokáže ochrániť FS bez integrity dát pri výpadku napájania a disku, ale FS s integritou a redundanciou nie.

[Andrej]

Btrfs RAID 5/6 je dávno vyřešené téma.

1. Write hole je nesrovnatelně menší problém než u „hardwarových“ (ha ha ha) AID nebo (hrůza pomyslet!) u AID typu dmraid / mdadm. Btrfs RAID 5/6 strčí vše zmíněné do kapsy, pokud jde o spolehlivost, už asi tak 5+ let.
2. Zbývající (hypotetické, teoretické, nikdy nikým nepozorované v praxi) problémy s write hole se týkají pouze metadat na Btrfs RAID 5/6. U Btrfs ovšem nikomu nic nebrání mít u RAID5 dat metadata typu RAID1 a u RAID6 dat metadata typu RAID1C3. Tím zmizí i poslední náznak teoretických problémů s write hole. A co teprve RAID1C4…

[j]

Tvle, tady je zas nablito ....

Nejdriv andrej, kterej zjevne nevidel v provozu vzivote nic co by stalo vic nez par stovek, protoze HW raid se pouziva vsude. A narozdil od SW raidu to umi vyrazovat disky driv nez se poserou a predevism to narozdil od toho SW raidu umi rict, kerej disk se posral.

A pak jenda, kterej zase netusi, ze fsck nikdy nic neopravi, protoze ani nemuze. fsck udela jen to, ze prepise rozjebanou strukturu do rekneme strukturalne konzistentniho stavu, coz prevazne vede k tomu, ze se zkurvi data. Takovej krasnej priklad "opravy" je to, ze skrati soubory ktery se tomu zdaj moc dlouhy. A udela to jednoduse proto, ze neexistuje zadna moznost jak by zjistil skutecnej stav.

Jinak viz AraxoN, jen dodam ze ten treti disk dat do jinyho HW. Raid se nepouzva proto abys neprisel o data, raid se pouziva proto, aby system byl provozni pri vypadku N disku, potazmo proto, abys ziskal nejaky ty IOps navrch.

Tzv sw raid vs btrfs je predevsim davna historie vs soucasnej pristup. U klasiky raid nastavis a tim koncis, nemuzes ho za provozu ani zmensit ani zvetsit. Definitivne a fixne je dana i multiplikace dat a odolnost proti vypadku.

To u btrfs neplati. Tam nemas raid na urovni bloku ale na urovni souboru, tudiz kdyz mas misto (a vic disku) tak ti muze to pole prezit (postupny)vypadek klidne i naprosty vetsiny tech disku. Navic ho kdykoli muzes podle potreby zvetsit nebo zmensit a je vpohode i s ruznejma "nenormalnima" konfiguracema (blby pocty disku, ruzny velikosti ...).

zfs je takovej pseudobastl na pul cesty mezi obema pristupama, a kombinuje v sobe nevyhody obojino. Bonusem se to rado neopravitelne posere a jeste to kdyz chces pouzivat cokoli z toho co by potazmo davalo smysl potrebuje nehorazny kvanta ramky.

---

Dete s tim guuglem dopice!

[Max]

Aneb J opět pokračuje v blábolech z minulosti, odkud utek jak zpráskanej pes.
Pokud nemáš s danými řešeními zkušenosti, tak se k nim laskavě nevyjadřuj jako pán tvorstva.
Proč by nešel automaticky disk vyřadit ze sw raidu a nahradit? Zřejmě jenom proto, že si to neumíš nastavit. Takže když to J neumí, tak to prostě nejde :D. Podobně není problém ani s identifikací vadného disku.
Ty jsi asi evidentně ani nezkoumal, jak fungují externí hw pole uvnitř. Některý externí storage dokážou ukázat víc, než by člověk čekal. Třeba některé storage od HPE je mdadm + nad tím vlastní workflow.

Pokud jde o ZFS, tak se mi ho nikdy nepodařilo rozbít, a že jsem se snažil. Měl jsem SLOG v ram, který jsem násilně sundaval, měl jsem vadnou ecc ram, měl jsem vadný řadič, dělal jsem pokusy se 100% zaplnění, simuloval jsem nedostatek paměti, tvrdých vypnutí nespočet. Oracle stále dodává big storage řešení nad ZFS, Nexenta je další známý příklad, QNAP to samé, TrueNAS to samé.

Navíc, pokud by jsi viděl nějaké současné technologie, tak by jsi věděl, že klasický raid, jak ho popisuješ, se upozaďuje, protože je to prostě shit s nevyrovnaným výkonem. Když měníš disk, je to pomalá operace, která ho navíc šíleně zatíží. Když se podíváš na řešení typu Nimble Storage (před pár lety to koupilo HPE, proto je to dobrý, nepochází to od nich :D), tak tam jasně vidíš podobný přístup jako má btrfs, nezajímají tě fyzické disky, zajímá tě kapacita. Když ti odejde jeden disk, tak se data z něj plynule rozprostřou na odstatní disky a tím pádem nekopíruješ 2TB dat na jeden disk, ale 2TB dat na 40 disků, takže pole máš po výpadku disku ve 100% stavu během chvilky.

Osobně mám zkušenosti se ZFS, BTRFS, NetApp, HPE MSA, HPE Nimble a pár dalších a nechápu tedy, proč pořád dokola opakuješ ty samé hovadiny o technologiích z doby minulé.
Zdar Max

[PetebLazar]

Když měníš disk, je to pomalá operace, která ho navíc šíleně zatíží.

Rychlost rebuildu pole je volitelnou ve většině HW/SW implementací RAID. U pole postaveném nad SSD by to asi nemělo představovat větší výzvu. Samozřejmě u HDD-based RAID mix sekvenční zátěže(rebuild) a náhodné zátěže(aplikace) uživatele asi nepotěší. Uvažujme v kontextu min. RAID6, kdy zbývající redunance zajistí po dobu rebuildu ochranu proti výpadku dalšího disku (doba rebuildu je volbou mezi vytizenosti a prodlužováním rizika vyplý́vajícího z dočasně omezené redundance). Nemám nic proti oprávněné glorifikaci ZFS, ale je třeba si uvědomit že úspěšná kariéra většiny zde leží právě na základech desetiletí úspěšného fungování zatracovaného HW/SW RAIDu.

Kontrola konzistence RAID pole se typicky provádí periodicky, co má ZFS za ekvivaletní aparát, který informuje o stavu kondice celé dostupné kapacity v rámci všech zúčastněných členů?

[Max]

Pokud snížíš rychlost rebuildu, tak zase prodloužíš čas, kdy se ti pole dostane zpět na 100%. Třeba v NetAppu mi dost často odcházejí dva disky po sobě.
ZFS má scrub + zaznamenává chyby při čtení i zápisu. Upozorní tě tak, že disk odchází dřív, než je mrtvý. Dále můžeš klasicky kontroloval SMART infa disků. Teď jsem třeba dostal po roce i hlášku, že jeden disk vykazuje chybu multipath. Sice jede, ale může být problém, takže by se měl preventivně vyměnit. Od SMART testů jsem postupně ustoupil, nepřijdou mi t ak vypovídající. Raději už jenom kontroluji chování disků a pár hodnot ve SMARTu.
A ano, mám zkušenosti jen se správou menších polí, malými krůčky se blížím 250TB polím na zálohy + běh VM. Proto jsem se už několikrát pana J ptal, s čím on má zkušenosti a s čím dělá. Člověk se ale vždy doví jen to, že všichni jsou idioti, jen on všechno ví nejlépe.
Zdar Max

[PetebLazar]

Používáte zfs-multipath či dm-multipath? Alan Jude v nedávném podcastu dával přednost dm-multipath.

[Max]

ZFS používám na FreeBSD, takže tam jedu GEOM_MULTIPATH.
Zdar Max

[Max]

Jinak dodám, že budu ZFS storage nejspíše migrovat na Linux, ale to asi až tak začátkem příštího roku.
Zdar Max

[j]

Dik za potvrzeni a nalezeni odkazu kterej sem sem chtel postnout, je na tom krasne videt, jak nerozumis ani zakladni funcionalite. Netusis jak funguje cache, nemas paru o tom jak funguje raid, coz ti opakovane vyvetluju a presto si to dodnes nepochopil.

Jako spraskanej pes zalezes vzdycky leda ty, typicky zacnes blejt sracky zcela mimo tema.

Krasna ukazka tvyho bliti sracek "se mi ho nikdy nepodařilo" === ty miliony lidi ktery resej se se jim to zcela samo a bez jakykoli zjevny priciny posralo ... neexistujou. A ano qnap je taky krasnej priklad, typicky se k tomu lidi vyjadrujou tak, ze to rozmlatej palici a vzivote to uz nechtej videt.

A stejne tak dalsi krasny potvrzeni, ze nemas paru

" Když měníš disk, je to pomalá operace, která ho navíc šíleně zatíží"

Pravda z toho neni ani jediny slovo. Kdyz se meni disk, tak se to v zavislosti na nastaveni chova dvema zpusobama 1) pole si disk otestuje a udela z nej novy spare 2) pole na nej po otestovani spare skopiruje, coz je linearni operace, nejrychlejsi existujici zpusob jak to udelat. Zaroven to pak funguje jako rozsireny test toho disku.

Jak rikam, nemas nejmensi paru o tom, jak veci fungujou, coz ti nebrani se tu navazet do tech, kteri to vedi.

Stejne tak je naprostej nesmysl, ze by se klasickej raid nahrazoval kvuli vymenam disku, protoze se nahrazuje predevsim kvuli operativnimu pristupu a moznosti operativniho rozsirovani nebo zmensovani konkretniho pole, pripadne dokonce kompletni redefinici raidu za chodu (proste se trebas z R5 udela R6 a pole si to nejak prebere)

Takze tu opet jen blejes hovna. Jako ve 100% svych postu.

Jo a aby se nereklo, chci videt tvoje workflow, ktery (v SW raidu) rekne, kterej ze dvou disku v zrcadle chcipnul. Cist i zapisovat se daji oba, fs nevidis. Pochlap se soudruhu.

---

Dete s tim guuglem dopice!

[PetebLazar]

Rebuild lze považovat za lineární (sekvenční) úlohu, ale operace ostatních klientů/aplikací za provozu mohou mít zcela jiný charakter, například transakční databáze (souběh takových zátěží není nic příjemného) a ne vždy je vhodná(možná) odstávka či odložení rebuildu do maintenance window (pokud takové dostatečně velké vůbec existuje).

Jak jsem osobně zastáncem klasického RAIDu. Zjištění o chování některých storage SSD/HDD z poslední doby (týkající se detekce chyb) mne trochu znervózňují. Je to právě detekce chyby(ať již pravdivá či falešná) na úrovni storage, jež na vyšší vrstvě (RAID) zajistí díky redundanci dostupnost dat. ZFS mne svou složitostí znervózňuje také, vzhledem k mým požadavkům i v otázce dosažitelného výkonu. Proti neustále opakovaným pro a proti bych radši viděl praktické srovnání těchto řešení postavené na HDD/SSD/NVMe.

Není třeba se uchylovat k vulgaritám, ty znevažují i případně relevantní argumenty.

[Max]

"J" ale neumí nic jiného, než být vulgární, v 90% případech nedokáže ani relevantně diskutovat, jen uráží, neustále a všechny.
Pokud ti odejde disk z nějakého pole, tak prostě chceš, aby to pole bylo co nejdříve opět ve 100% stavu. Pokud ti odejdou dva disky, tak to chceš o to víc. Jak už jsem napsal, snížení rychlosti rebuildu je k ničemu. Pokud mám dva disky off a třetí by byl už problém, tak opravdu nechci dvě hodiny čekat, zda se stihne rebuild, nebo zda odejde další disk.

Pokud jde o ZFS, nepovažuji ho za nijak složité, je to podobné jako btrfs, jen má více možností minimalizovat CoW režije. A člověk samozřejmě musí umět správně sizovat a navrhovat řešení, protože změna u ZFS není možná, co jednou do poolu přidáš, to neodebereš. Každopádně s pár zkušenostmi to pak není problém.
Osobně jedu doma btrfs pro menší storage (domácí nas, 18TB pole jen pro pár věcí, výkonově mi to stačí, není potřeba tolik ram, je to 100% nativní v Linuxu atd.) + pro počítače (desktop, ntb). ZFS jedu tam, kde potřebuji velkou kapacitu úložiště s téměř neomezeným nafukováním do budoucna.

Pokud jde o detekce chybných disků, tak jsem se přesunul prostě k detekci špatného chování. ZFS to pozná + napoví i info ze SMART disků, což je okamžitě notifikováno.
Zdar Max

[Max]

Každý si může ten thread přečíst a vidět, co tam píšeš za hlouposti, jak tam meleš šroty o kešování, fcí řadičové vs diskové keše, nemáš tam ponětí o ničem a nesmyslně jsi se dostal do argumentačího faulu a snažil jsi se obhajovat totální nesmysly. Podobně, jako to děláš nyní a jako jsi to dělal v minulosti u jiných věcí.
To samé tady, ignoruješ nevýhody klasického pole a výměny disků, které jsem zmínil a děláš jakoby ze sebe chytrýho a přitom tu máváš R5 a R6 poli, které patří do dávné minulosti.
Opět, to, že něco neumíš nastavit, nebo že tomu nerozumíš, to opravdu neznamená, že to nefunguje, to jen znamená, že jsi levej, nebo línej.
Dále, bavíme se tu primárně o aktuálních technologiích, tedy btrfs a zfs, který jdou evidentně totálně mimo tebe.
Pokud nevíš, jak se rozeznává chybný disk, tak bohužel, jakékoli další vysvětlování je zbytečné.
Zdar Max

Teda jako... "j" se určitě dokáže s tebou hádat a hájit se sám, ale dosud jsem si myslel, že právě "j" je zastáncem btrfs a ani tento ani tehdejší thread mě nějank nepřesvědčily o opaku.

[Max]

A to jsi pochopil z toho, že uznává jen hw raid? :D
Zdar Max