Dotaz: RHEL/Centos 8 a BTRFS

[filbar]

Ahoj, chtěl bych se zeptat na to, jaký je stav BTRFS v RHELu/CentOSu 8? Cosi jsem četl, že s ním RH moc už nepočítá.

Uvažuju o něm na datový disk s weby z důvodů podpory snapshotů jako doplňku ke stávajícímu zálohování. Prozatím jedu na standartním FS CentOSu. Jak je to se stabilitou BTRFS? A jak moc snapshoty zaplňují disk?

Předem děkuji za odpovědi.

Odpovědi

[Max]

Podpora je dána verzí kernelu (4.18.0-80) a btrfs progs (4.20.2). Kernel jde naladit i novější, třeba tím v elrepo (aktuálně je tam kernel 5.6).
Co ti která verze kernelu a progs přinese viz : BTRFS changelog

Velikost snapshotu je podle velikosti rozdílu změny dat, takže velmi hospodárná varianta.
Se stabilitou btrfs jsem neměl problémy.
Zdar Max

[bigBRAMBOR]

nicméně v instalátoru už s ním opravdu nepočítají a vyřazen byl už nějaké verzi 7.něco

z dotazu jsem nepochopil co přesně myslí tím, že s ním už moc nepočítají

[Max]

To s tím nepočítáním je asi kvůli tomu, že RHEL upustil od podpory BTRFS a věnuje se primárně XFS a Stratis.
Nicméně v kernelu a všude jinde je, takže nevidím problém.
Zdar Max

[Max]

Jinak upozorním, že o konverzi ext4 na btrfs se nemluví jako o dobrém řešení. Tj. pokud btrfs, tak nedělat konverzi z jiného fs, ale čistý formát.
Zdar Max

[Michal Kubeček]

Co si mlhavě vzpomínám (vysvětloval nám to jeden z vývojářů někdy v době, kdy jsme začínali s podporou ve SLE, tj. asi tak 2013), ta in place konverze by měla fungovat tak, že se v podstatě nechá ext4 tak jak je, kolem toho se vytvoří metadata btrfs a až nové věci a to, s čím se hýbalo, jsou skutečně btrfs. Takže pokud jsou tam větší části, na které nikdo nesahá - což je u většiny filesystémů obvyklé - budete vlastně pořád (nebo aspoň hodně dlouho) pracovat s hybridem dvou filesystémů. Nemluvě o tom, že tahle věc těžko bude tak rozsáhle a důkladně otestovaná jako filesystém vytvořený od začátku jako btrfs.

[lkocman]

Ahoj,

Red Hat tlačí na xfs spolu s LVM jako preferované řešení, a aktuálně nemají dedikovaného btrfs maintainera (býval jeden), zatimco v SUSE zase dlouhodobě podporujeme a doporučujeme btrfs. Takže každému dle preferencí.

Pokud je pro tebe btrfs jako daný filesystem velmi důležity a chceš mít rozumnou podporu v případě nějakého problému, tak bych raději šáhl po openSUSE Leapu jako ekvivalentu SUSE Linux Enterprise, od další verze (15.3) budeme mít dokonce identické binárky.

Jako "důležitý storage server" někde ve firmě bych spíš opravdu zvolil ext/xfs + lvm na RHEL/CentOS, nebo btrfs na openSUSE/SLE. Ať se nedostaneš do problému, že ti nebude nikdo reagovat na bugu.

Luboš

[Andrej]

Btrfs je samozřejmá nezbytnost a dnes standardní souborový systém, společně se ZFS jeden ze dvou použitelných při dnešních kapacitách disků. (Přece jen už nejsme v dobách jednoho neredundantního 10 GB disku, že ano.) Nemluvě o tom, že také pro systemd se Btrfs nedávno stal nezbytnou samozřejmostí, pokud chce uživatel opravdu plně využít všech vlastností systemd.

Cosi jsem četl, že s ním RH moc už nepočítá.

Na distru tohle nijak nezávisí. Podpora v kernelu samozřejmě byla, je a bude. Vím, že na kernelovém mailing listu Fedory nedávno pár datových kaskadérů začalo hloupou debatu kolem zrušení „podpory“ pro Btrfs, ale naštěstí se tam včas nechali slyšet rozumní lidé a celý nesmysl utnuli.

Kromě toho, i případné zrušení „podpory“ v nějakém distru nemůže znamenat nic víc, než že (dejme tomu) btrfs-progs nebudou automaticky na „core“ seznamu balíčků, které jsou vždy automaticky nainstalované, ale uživatel si je bude muset jedním příkazem instalátoru doinstalovat. ( Hrůza!!!) Žádné distro si nemůže dovolit zrušit podporu Btrfs v kernelech, ve fstab a ve všem možném dalším.

Takže Btrfs. Jednoznačně.

Jak je to se stabilitou BTRFS?

Nevím, jestli tohle má být vtip. Nebo je to otázka z roku 2010, 10 let zapomenutá a nepoložená? Máme rok 2020.

Když si dohledáš například nedávné kritické bugy Ext4, které vedly ke ztrátě dat (a přicházely celkem pravidelně přinejmenším jednou za 5 let), řekl bych, že o „stabilitě“ Btrfs není třeba nijak moc hloubat. Nebo ještě jinak: Co to je, taková stabilita? S čím srovnáváme?

A jak moc snapshoty zaplňují disk?

Jako každá jiná data. Podle toho, jak moc do nich zapisuješ.

Spíš by ses měl ptát, jak moc místa můžou snapshoty ušetřit ve srovnání s kopírováním. Což taky záleží na tom, jak moc se nakonec budou vzájemně lišit.

[pavele]

V RHELu/CentOSu 8 není btrfs podporován. Můžeš to zkusit jako já s CentOS 7 a jako já už potom po restartu nenabootuješ.

Pokud chceš btrfs, tak asi SUSE.

RH tlačí xfs. SUSE tlačí btrfs.

Až bude btrfs stabilně používaný ve všech velkých linuxových distribucích, bude to znamenat, že dozrál k běžnému použití a není už potřeba včera vydaný kernel s rolling-updates distribucí.

Ovšem bez průkopníků typu Andrej se vývoj btrfs neposune.

[Michal Kubeček]

…a teď se pro změnu vraťme do reálného světa, kde byl btrfs podporovaný ve SLES 11 SP2 (tj. enterprise distribuci, s jádrem 3.0) už na podzim 2011. Tolik k těm průkopníkům a včera vydanému kernelu.

[Andrej]

V RHELu/CentOSu 8 není btrfs podporován.

Co si vojín Kefalín představuje pod pojmem podporován? Sorry jako, ale na tohle tupé, pokrytecké a bezvýznamné slovo, podporován, mám alergii.

Zkusme nějak definovat, co přesně to znamená, že někdo podporuje Btrfs. To jako že aktivně přispívá do kódu Btrfs, provozuje benchmarkovací farmu s tímhle filesystémem a přispívá nové vlastnosti nebo zlepšení výkonu? Jestli ne, tak potom ten někdo nic nepodporuje a má držet zobák a krok.

Můžeš to zkusit jako já s CentOS 7 a jako já už potom po restartu nenabootuješ.

Tak to bych se vsadil, že nabootuju. Ale špatné distro zkoušet nehodlám.

S implicitním vanilla kernelem prostě Btrfs 100% funguje už asi tak od roku 2009. Jestli nějaké distro podniklo zvláštní úsilí směřující k tak sprostému cíli, abych s Btrfs, což Linux i GRUB prostě podporuje, najednou nenabootoval, pak to distro nestojí za můj čas a mé úsilí. Fakt nevím, co jiného k tomu říct.

RH tlačí xfs. SUSE tlačí btrfs.

XFS je technologie 80. a 90. let 20. století. Btrfs je technologie pozdních 0., 10. a 20. let 21. století. Každý ať si vybere, co chce. K SGI Indy, Octan a Fuel sice vzhlížím s jistou nostalgií, ba i to bachraté Tezro bylo super, ale to ani náhodou neznamená, že bych chtěl jejich filesystém pro jednogigabytové disky mít na dnešním hardwaru!

Až bude btrfs stabilně používaný ve všech velkých linuxových distribucích, bude to znamenat, že dozrál k běžnému použití a není už potřeba včera vydaný kernel s rolling-updates distribucí.

Bla, bla, bla. Prostě sis vymyslel slovo stabilně, pro které nemáš žádnou racionálně zdůvodnitelnou definici.

Opravdu nevím, proč by někdo trval na podpoře ve všech distribucích, včetně špatných, zastaralých a jinak pochroumaných distribucí. Navíc to nezávisí na distribuci; podpora Btrfs je implicitně v kernelu i v běžném userspace zapnutá.

Na všech mých strojích mám Btrfs od roku 2010, na prvních od roku 2009. Kernel, který tenkrát byl, není včera vydaný. Dokonce se tak starý kernel už nedá sehnat ani v LTS podobě.

Jo, že někdo zaspal v roce 2010 (nebo dříve), to už je jeho problém. Svět se zatím posunul o kousek dál, víme???

Ovšem bez průkopníků typu Andrej se vývoj btrfs neposune.

Jsem přesným opakem průkopníka. Používám léty prověřenou, osvědčenou a jedinou dnes použitelnou technologii v oblasti filesystémů na Linuxu, tedy Btrfs. (Kdybych nebyl líný, možná i to ZFS bych ještě rád používal, ale jsem líný, takže nic.)

Hlasitě se směju těm amatérům, kterým už podesáté Ext4 posral data, ale oni si zase a znova nainstalují Ext4, protože 11 let starý Btrfs je podle nich „nestabilní“. Nebo si nainstalují XFS. Výborně. Snapshoty to má kde? RAID vestavěný do filesystému to má kde? Když k tomu XFS oddílu budu chtít přidat druhý a za provozu, bez restartu to transformovat na RAID1 — samozřejmě s duplikací pouze těch bloků, ve kterých jsou opravdu data —, jak to udělám? Aha, nijak. Smůla!

Kdyby hloupost kvetla, některým lidem by čouhal tulipán z prdele.

[Aleš Kapica]

Tak to bych se vsadil, že nabootuju. Ale špatné distro zkoušet nehodlám.

Přesně tak. Od toho jsou tady jiní mistři slepých uliček.

[ewew]

Definícia slova "stabilný" je stav daného objektu, ktorý sa nemení tak často a aj keď dôjde k zmene. Tak táto zmena nemení zásadne funkčnosť.

Slovo "nestabilita" znamená sat objektu, ktorý prechádza neustále zmenami.

Označovať ostaních čo tvrdia opak tvojích tvrdení je tiež smiešne. Pokial viem, tak z extX súborového systému dokážeš získať data ak nie sú fragmentované. Pod fragmentovaním myslím rozdelenie súboru na časti podľa volného miesta. Pritom pri dynamickom vytváraní štruktúr dochádza k nepredvídatelnému fragmenotvanie na úrovni blokov. Z tohto nedostaneš ani jeden súbor. Amatérským spravovaním systému možno považovať aj zkopirovanie zo zálohy. ExtX nespadne kvôli nedostatku volných blokov.

[Pavel 'TIGER' Růžička]

Obnova dat s extX záleží i na úložišti. Dejme tomu, že z nějakého HDD je možné něco vytáhnout, ale v dnešní době SSD se s daty rozluč, pokud nemáš zálohu. Obnova dat byla vždycky pakárnou a byla pochopitelná v dobách, kdy cena médií byla trochu jinde. Dnes je mnohem výhodnější mít propracované zálohování. V takovém případě je skutečně btrfs někde jinde a to myslím ku prospěchu tohoto fs. Na druhou stranu chápu, že pro mnohé může být kanonem na vrabce a dokonce v některých rukách se z něj skutečně může stát nestabilní fs.

Pro extX je většina instalátorů linuxových distribucí a uživatelé to většinou nechávají být ve výchozím stavu, protože nejsou schopni posoudit, jestli změna fs pro ně skrývá nějakou výhodu. Já osobně volím fs podle projektu na který má být použit. Někdy si plně vystačím s extX, jindy je mi jasné, že dokáži plně využít potenciál btrfs. Ovšem u obého je prioritou důkaldné zálohování, pokud se jedná o nepostradatelná data.

[Andrej]

Nestabilita je zoufalý filesystém z 20. století, kterému došel dech někde na 10 GB discích. Třeba Ext4.

Stabilita je současný filesystém hodný 21. století, který má checksumy dat i metadat a redundanci podle libosti.

Nějaké otázky? Já bych řekl, že všechno podstatné už bylo řečeno.

Jasně, z ExtX prý získám data. A co když se mi posralo médium, na kterých ta data údajně byla? Kde má ten pseudo-filesystém zálohy? Na kterých dalších médiích je? Jak u něj vypočítám RAID5? A.h.a. O čem se tady vůbec bavíme?

Někdy mi připadá, že diskuse typu „Btrfs nebo něco jiného“ jsou totéž jakou diskuse typu „osel nebo auto“. Sorry jako, ale osla místo auta nechci. Kdo jo?!

[Pavel 'TIGER' Růžička]

A zase to odnese chudák osel. Vždyť je obdivuhodné, co to zvíře unese po cestách, kam se auto nedostane.

[pavele]

Otázečka by byla. Kdy bude btrfs vyhlášen vývojáři za stabilní? Podle:

https://btrfs.wiki.kernel.org/index.php/Main_Page

https://btrfs.wiki.kernel.org/index.php/Status

"The Btrfs code base is under heavy development. Not only is every effort being made to ensure that it remains stable and fast but to make it more so with each and every commit. This rapid pace of development means that the filesystem improves noticeably with every new Linux release so it's highly recommended that users run the most modern kernel possible."

[Pavel 'TIGER' Růžička]

Odhaduji to, že až budou všechny políčka zelená a nápisem OK.

[lertimir]

Ale to pak patrně nebude nikdy. Protože např tak silně diskutovaná nestabilita v RAID 5/6 reálně v praxi už skoro nikoho zajímat nebude. protože RAID 5/6 je čím dál více k ničemu. Jinak řečeno výhoda proti RAID 1, kdy potřebuji méně paritních disků, je převážena nevýhodou, rychlost při zápisu je výrazně degradovaná. Degradace je způsobena tím, že pokud zapisuji méně než strip, Tak nejdříve musím strip přečíst, provést změnu spočítat parity a znovu změněné do stripu zapsat. Což jsou 2 IOPS operace na všech discích na jeden požadavek zápisu. A tahle nevýhoda je stále stejná, možná i díky stále se zvětšujícím kapacitám roste i mírně velikost stripu, na druhou stranu cena media stále klesá. Navíc poměr rachlosti přenosu ku kapacite (pro jednu technologii) pořád klesá, rychlost roste pomaleji než kapacita (kromě NVMe)

Pro mne je RAID 5 technologie 90 let a vyhnu se jí kdekoliv a takže faktická neexistence RAID 5/6 v btrfs mi nijak neva.

Asi jediné, co by btrfs slušelo, a co zatím nemá, je integrované šifrování. Pokud jedu btrfs raid 1 nad LUKSem, tak potřebuji pro každý disk samostatný LUKS a jiný klíč a nemám jeden pro všechny.

[Filip Jirsák]

Jsou užití, kde je důležitější kapacita než rychlost zápisu. Třeba úložiště záloh. Kde se zároveň hodí schopnost btrfs, že tam nastrkáte různé typy disků.

[lertimir]

To nepochybně. A v podstatě pišeš to co já. Linku argumentace byla taková.

RAID 5 dělám, když chci redundanci. (jinak stačí třeba JBOD) Ale v tom případě je v současnosti lepší zvolit redundanci btrfs RAID 1, jednak mám různé typy disku, jednak mi checksum najde lokální silent coruption a také to mám rychlejší. Cenou proti tomu je že mám více redundantních disků. A u RAID 5 jsem neuvedl jeětě jednu podstantou věc. A tím je "unrecoverable read error rate (URE)" Ten je v současnosti 10^15 u velkých disku a 10^14 u menších viz. To znamená 125 TB nebo 12,5 TB. A pokud ti v RAID 5 poli padne disk, po výměně za nový děláš rekonstrukci pole, tak musíš přečíst z ostatních úplně všechno. Pokud je tam jedna chyby padne pole jako celek a nedá se postavit ten čtvrtý disk. Pro pole např 4 x 4TB disků tak při rekonstrukci čteš 12 TB abys vypočetl ty 4 zbylé. A pokud je URE 10^14 tak pravděpodobnost, že při čtení na nějakou chybu narazíš je už dost velká. viz se zlepšeným URE se k tomu bližíme znovu. RAID 4x16TB přečte 48 TB na rekonstrukci sice ten poměr je o něco lepší ale také to nic moc není viz

Před asi 6 lety se mi to stalo s mdraid a od té doby jsem s RAID 5 skončil, kromě jediného ještě zbylého pole které dojíždím a mám data také i jinde. RAID-5 je o málo lepší než JBOD a RAID 1 je výrazně lepší s tím že btrfs RAID1 díky chceksum řešit i chyby a dokud se URE netrefi do stejného bloku tak se nic neděje.

[Filip Jirsák]

Akorát je mezi RAID 1 a RAID 5 ten drobný rozdíl, že když budete chtít postavit 12 TB pole z 2 TB disků, pro RAID 1 potřebujete 12 disků, pro RAID 5 jen 7 disků.

[Michal Kubeček]

Na základě předchozí zkušenosti jsem si plně vědom pošetilosti a marnosti svého počínání, ale nedá mi to, abych se přesto nezeptal: ten RAID5 ze sedmi disků vám opravdu připadá jako dobrý nápad? Myslím pro použití v praxi, ne jen jako teoretická konstrukce sloužící výhradně pro potřeby argumentace v rámci řečnického cvičení.

[Peter Golis]

Pokiaľ to budú SSD alebo NVMe, tak v tom nevidím ani najmenší problém. Ale ja mám veľmi liberálne názory.

Ostatne, v rámci produktovej kategórie ALL Flash Storage sa už dávno predávajú diskové polia s SSD alebo NVMe blokovými zariadeniami. A dokonca sa predávajú aj servery ktoré sú plne naložené takými SSD/NVMe diskami. Plne naložené, nie len s jedným radom diskov na prednom paneli, ale s plným disk shelfom.

[Michal Kubeček]

Ta otázka nebyla kvůli samotnému počtu disků v poli, to samozřejmě vím, že se běžně používají pole o mnohem více než sedmi discích. Ale rozhodně nejsou navržena jako jeden RAID5, protože by to sloužilo jako teoretická ukázka, že to tak technicky udělat lze, ale praktická míra redundance a spolehlivosti takového pole by byla tak nízká, že by to nedávalo smysl. Viz např. tento starší článek a novější doplnění.

[Peter Golis]

Narážal som na to, že pri zlyhaní jedného z rotačných diskov sa môžu ostatné disky useekovať k smrti pokiaľ nedobehne rebuild a diskové pole sa bude aj naďalej používať na plno. u Flash Storrage tento problém so seekovaním odpadá, ak človek nebol blbý a nepoužil typ SSD s nevhodnými pamäťovými bunkami (TLC/QLC/...), podobne ako keby použil do RAID poľa rotačné disky so šindelovým zápisom.

Ohľadne informácií o zastaraní single a double parity, to je známa vec nielen u RAIDu ale aj u deduplikácii. Preto sa už dávno prešlo na Triple Parity (RAID-7, RAID-Z2 a podobne).

Ostatne, podobný problém s zvýšením záťaže na disky prirebuilde poľa a tým pádom aj s pravdepodobnosťou že nejaký zvyšný disk z toho zlyhá je aj pri RAID-1. Takže otázka ktorý typ RAIDu je najvhodnejšie použiť nemá generickú odpoveď. Všetko závisí od potrebnej funkcionality a cenového stropu pri nadobúdaní, možného upgrade a cene za údržbu a prevádzku.

[lertimir]

A takové pole stojí ranec. Nic nemám proti polím, které ranec stojí, ale myslím si, že je velmi na zvážení, jestli nemit levné pole a levné disky a bezpečnost a mnohdy i rychlost dosahovat vysokou redundancí, než mít vysoce drahé pole, které je rozumně spolehlivé s RAID 5 či jinou nižší mirou redundance. Co má při stejné míře bezpečnosti nižší TCO není jednoznačné a rozhodně to nemusí být RAID 5.

[Filip Jirsák]

Tak si vezměme nějaký reálnější příklad. Pole složené ze čtyř stejných disků, kapacita pole je dvojnásobek kapacity jednoho disku. S RAID 1 je odolné proti výpadku 1 disku, s RAID 6 je odolné proti výpadku 2 disků. Podle mne má to pole s RAID 6 vyšší redundanci.

[Aleš Kapica]

S RAID 1 je odolné proti výpadku 1 disku, s RAID 6 je odolné proti výpadku 2 disků. Podle mne má to pole s RAID 6 vyšší redundanci.

To platí za předpokladu, že použijete MD raid. Pokud se použije Btrfs, záleží, kolik je na tom FS dat.

[Filip Jirsák]

Je to naopak, pokud by se použil pravý RAID1 nad 4 disky, bude mít kapacitu jednoho disku a přežije výpadek 3 disků. Já jsem myslel zrcadlení, tedy to, co btrfs nazývá RAID 1. Pokud budu mít btrfs nastavené, že data mají být alespoň na dvou discích, při výpadku dvou disků mohu o nějaká data přijít.

[\/\/\/]

Co se stane s mými daty, když se mi na filesystému s checksumy dat poškodí ta data?

Když mám N x data, umístěná na několika zařízeních, a k tomu checksum, tak patrně ztráta nebo špatné čtení jedněch dat přinutí fs, aby rozhodl, která data jsou správná a případně udělal opravu.

Když mám 1 x data, ale rozhozená po částech na několika fyzických zařízeních, a k tomu checksum, tak ztráta části dat na jednom fyzickém zařízení patrně přinutí fs, aby dopočítal správná data a případně udělal opravu.

Když mám 1 x data a k tomu checksum, tak po ztrátě dat mám i s celým checksumem smůlu. Ale dozvím se to.

Je to tak?

[Aleš Kapica]

U Btrfs v raid1 máš checksum + 2x data. Je to cow systém, takže pokud FS při čtení zjistí, že je u bloku který čte primárně nesedí checksum, použije ten druhý a zapíše nové dva bloky s novým checksumem.

Účelem kontrolního součtu je rychlá kontrola datového bloku, nikoliv jeho obnova.

Pokud máš Btrfs v single módu, seš v loji, pokud nemáš pod ním nějaký mdraid. Ovšem v takovém případě se o správnost datového bloku nestará Btrfs.

Btrfs v raid56 by mělo mít navíc k dispozici ještě jeden datový blok s kontrolním součtem ze kterého se měl dát poškozený datový blok rekonstruovat. Ale nevím. Tak hluboko do toho nevidím.

[Filip Jirsák]

Co se stane s mými daty, když se mi na filesystému s checksumy dat poškodí ta data?

Systém by to měl detekovat. Následně záleží na tom, zda ta data má ještě někde jinde, odkud je může obnovit.

Je to tak?

Netuším, nepochopil jsem zadání. Co znamená „1 × data“? Myslel jsem, že to znamená, že každý blok je zapsán jen na jednom místě. Pak ale není pravdivé to druhé tvrzení, protože pokud bude blok zapsaný jenom jednou, nebude odkud ho dopočítat.

[\/\/\/]

Co znamená „1 × data“? Myslel jsem, že to znamená, že každý blok je zapsán jen na jednom místě. Pak ale není pravdivé to druhé tvrzení, protože pokud bude blok zapsaný jenom jednou, nebude odkud ho dopočítat.

Jestli to dobře chápu, tak v normálním raidu5 mám data rozložená po částech na N disků, tj. mám je právě jednou, a k tomu mám navíc na dalším disku ještě informace (checksum??), které umožňují při ztrátě jednoho disku původní data obnovit.

Na btrfs raidu1 mám data uložená 2x a k nim mám checksum.

Jen tak nad tím přemýšlím a pořád jsem ještě nepřišel na to, kde bych dokázal využít btrfs raid-něco. Používám btrfs sice v několika případech, ale v podstatě jenom kvůli snapshotům. Málo disků...

[Filip Jirsák]

Nikoli. Na RAID 5 se třemi disky máte na 1. disku uložený blok A, na 2. disku blok B a na třetím disku blok A xor B. Když kterýkoli z těch disků odejde, dokážete kompletně obnovit všechna data. S větším počtem disků se to bude lišit – klasický RAID 5 bude mít vždy na N-1 discích klasické datové bloky a na 1 zbývajícím disku bude XOR všech těch bloků (s tím, že disk, kde jsou XORovaná data, se střídá, aby to bylo rovnoměrně rozložené přes všechny disky). U btrfs je to jinak, tam si určujete, kolik kopií dat chceme mít. Takže když postavíte btrfs RAID 5 ze šesti disků, a data budete chtít mít dvakrát, bude zase na jednom disku blok A, na druhém blok B a na třetím blok A xor B – a tahle trojice bloků bude uložená někde na těch šesti discích tak, aby každý blok z té trojice byl na jiném disku.

[\/\/\/]

Sorry jako... Vy si tak libujete v přesnosti definic, že byste také mohl přesně napsat, co tam mám já napsané blbě. Protože jediné, co jsem napsal nepřesně, je ten checksum v závorce. U něj jsem pro jistotu napsal dva otazníky, protože jsem nevěděl, co je to za informaci, která je na raidu5 navíc a jaksi jsem i sám vytušil, že z checksumu původní data nedopočítám.

[Filip Jirsák]

Špatně tam máte to, že data jsou uložena po částech (blok je vždy uložen celý) a úplně vám tam chybí to, že je vždy N datových bloků a N+1 blok je XORem těch předchozích (u RAID6 jsou takové bloky dva). Checksum s tím nijak nesouvisí, ten si btrfs ukládá u všech bloků a slouží jen k ověření toho, že zapsaná data nebyla poškozena.

[j]

Bozinku, Jirsak opet zvani o vecech o kterych nic nevi ... jak jinak taky ze? Tahni radsi na ruut.

Jirsaku, R5 na btrfs funguje PRESNE stejne jako R5 na cemkoli jinym. Kdyby to fungovato tak jak ty pises, tak by 6ti diskovy R5 melo DVA disky na paritu a pri 4 discich by bylo treba na paritu k tomu jednomu pridat jeste 1/3 dalsiho, ze? To je picovina co? Nj, aby nebyla, napsal to Jirsak.

Ale ja vim, pocty prvni tridy ZS jsou pro tebe zcela nezvladatelny.

---

Dete s tim guuglem dopice!

[j]

Ani ne.

R6 je vzdy odolny proti vypadku 2 disku. Kdyz pouzijes R1 v provedeni btrfs, a umrou ti dva disky zaroven, tak je to pole mrtvy. Musel bys mezi vypadky tech disku pustit rebalance, a musel bys tam mit dost mista.

Jenze presne totez, plati i pro R5/6 => pokud mas dost mista, a stihnes rebalance, tak na polich (nejen) s btrfs, muze takovy pole prezit postupny vypadek klidne i vetsiny disku.

Vzdycky tudiz plati, ze R6 je bezpecnejsi varianta. A R5/R1 je v pripade btrfs co se tyce bezpecnosti exaktne stejna = prezije vypadek jednoho disku. (hypoteticky, ses schopen R1 rychlejs zrekonstruovat, ale to je taky cira teorie, protoze ve finale bude bottleneck disk na kterej zapisujes, a ten bude davat v obou pripadech presne totez)

---

Dete s tim guuglem dopice!

[lertimir]

A zkusil jsi reálně provozovat RAID 6? Myslím skutečný provoz. Totiž se stejnou myšlenkou jako jsi prezentoval (tedy hurá RAID 6 nad čtyřmi disky mi vydrží výpadek dvou disků, budu tam mít hlavní zálohy) jsem před lety zkusil běžet BackupPC jako zálohovací stroj pro systémy doma. Tehdy asi 6 strojů. A byla to rychlostní katastrofa, naprostá katastrofa s rychlostmi zálohování pod 10MB/s. A když jsem to pak konzultoval s kluky, kterí dělají správu systémů u nás na univerzitě potvrdili to samé. Při zátěži zápisu rychlostní katastrofa. Všude od toho utekli. Takže ano RAID 6 někdy v nějakém specifickém případě, kdy násobně více čtu než píšu. Ale to není backup. do backupu se vlastně jen zapisuje a čte se jen při problému. Výkonnostní cena za lepší redundanci v RAID 6 je obrovská.

Ale já nijak nemám potřebu se tady s tebou hádat. Jen říkám, že v RAID 1 je pro mne cena za duplicitu disků přijatelná pro dobré zajištení bezpečnostní. Pro RAID 5 ušetření za disky nevyváži rizika spojená s rizikem pádu celého pole při rekonstrukcí a nižším výkonem. A pro RAID 6 zase lepší redundance nevyváží obrovský výkonový propad. Pokud máš jiný názor na poměry, co je cennější, tak v pohodě, rozhoduj se podle toho.

[Peter Golis]

Prečo by s RAID6 mal byť nejaký problém? Proste sa vytvorí nad celým disk shelfom, a nechá sa cca 10% diskov v poli ako spare.

[lertimir]

Problém není, pokud nevadí propad v IOPS.

[j]

Tusis vubec o cem zvanis? Zjevne nemas ani paru, ze?

Vis co dela BTRFS bez ohledu na to, jestli vubec je v libovolny raid konfiguraci? Pred kazdym zapisem kazdej blok precte, a zapise ho jinam. Takze se zadnej propad ani teoreticky konat nemuze, ze?

A to nemluvim o tom, ze nejen nemas zjevne o btrfs, ty nemas ani paru o tom, jak fungujou pole a co se pouziva. R6 je naopak poslednich par let prakticky jedina pouzivana konfigurace.

---

Dete s tim guuglem dopice!

[Peter Golis]

A aký výkonnostný prepad v IOPS bude mať pole, ktoré má cca 10% diskov ako spare (teda pole ktoré má 10 alebo viac diskov)?

[Peter Golis]

Áno. Také pole je drahé, a má špecifické určenie. To nie je na domáce strihanie filmíkov z nejakej gopro kamerky. Také polia sa používajú v kadejakých cloudoch kde diskové pole dokáže deduplikovať dáta na VM a DB.

Ale single parity, to do takých polí nepatrí.

[Pavel 'TIGER' Růžička]

A vadí ti v něčem, že vývojáři jej ještě nepovažují za stabilní? Vždyť to je v linuxu celkem normální stav a přitom věci jsou normálně použitelné, jen při náhodných shodách různého hardwaru se to může chovat nekorektně. Ale to se netýká jen FS. To šifrování by nebylo marné, pro mne je to zatím nepodstatné, protože šifruji minimálně. Ale chápu tu potřebu.

[lertimir]

Nevadí. Vůbec. Ty vrstvy které jsou podstatné jsou stabilní. A některé položky, které mají oranžové, tak je to pochopitelné např. když se dělá rebalance tak to postihne výkon, protož interní sturktura se přeprecovává a jinak to být asi nemůže. Práve proto, že mi to v zásadě pouze prohlášení nevadí jsem ten post psal. Jediná nestabilní věc je RAID 5/6 a myslím že už nikoho moc nezajímá, tak se na tom skoro nepracuje. Mnohem zajímavější věc je v RAID 1, a to optimalizace toho, aby při čtení byla data dodávána z obou disků s maximální účinností vzhledem k jejich jednotlivé zátěži.

[j]

Blabol roku si zarucene vyhral hosane, je videt, ze si pole nevidel ani z rychliku.

R1 se nepouzival prakticky nikdy, krome mozna par domacich zrcadylek. Pouzivalo se R10. A jestli je neco dneska mrvy, tak prave tohle, vsechny soudoby pole jsou bydefault R6. A to neprekvapive prave proto, ze je to vykonostne uplne jedno, setri to pocet disku a je to bezpecnejsi. On totiz tu R10 polozi vypadek pouhych 2 disku, ze? Kdezto na R6 by musely umrit 3, ze?

R10 se totiz pouzivalo primarne a predevsim kvuli ziskani IOps, coz jaksi s SSD neni treba.

A blabolit tu o cteni v pripade prepisu ... lol, co asi tak dela kazdy SSD s kazdym jednim zapisem, bez ohledu na to, jestli je nebo neni v poli.

R5/6 pak v btrfs naprosto vpohode funguje.

---

Dete s tim guuglem dopice!

[j]

Na distru to zavisi v tom smyslu, ze pokud budes chtit vyuzit jejich support (nebo si ho dokonce platis) tak te s tim poslou do haje.

---

Dete s tim guuglem dopice!

[Leinad]

Za sebe používám Btrfs na openSUSE a po každé, když to zkusím, tak toho hodně lituji. I právě teď s posledním Leap 15.1, kdy mi Btrfs balance klidně běží dva dny s nulovým posunem nebo kdy mi kvůli btrfs scrub nenabooval systém. (první bug reportovaný, druhý jsem připsal k němu v komentářích, ale asi si zaslouží reportovat samostatně)

Na druhém počítači tyto problémy nemám, ale zase mě naopak štve, že občas se počítač "škubne", nejspíše když si na pozadí spustí nějakou kontrolu. Což s ext4 nedělalo

[Pavel 'TIGER' Růžička]

OpenSUSE jsem měl nasazen v jedné organizaci hodně dlouho, avšak upgrade z 13.2 na 42.1 tu dlouholetou spokojenost rozbil na padrť. Co mohlo se rozbít, to se rozbilo. Tehdy jsem neměl dostatek časoprostoru řešit problémy systému ale napadla mne spásná myšlenka, upgradovat totálně rozbitý systém na Tumbleweeda, což se povedlo a vše začalo opět bezchybně fungovat. Hardware tak dožil na Tumbleweedu. Tím chci napsat, že ta chyba nemusí nutně být ve file systému jako takovém. Nicméně z logů by neměl být problém vyčíst, kde je vlastně chyba.

[lertimir]

Souhlas Opensuse jsem používal od nějaký 10.1 (nebo možná i dříve už si nepamatuji) do 42.1 ten upgrade nebyl šťasný. Pak jsem jej opustil směrem na Arch. A btrfs používám úplně všude jak na SSD tak na HDD k plné spokojenosti. S pravidelně nastaveným automatickým scrub na týdenní bázi a na měsiční bázi ballace

[Michal Kubeček]

42.1 byl tak trochu uspěchaný experiment, nemluvě o tom, že jádro, které se tam použilo, nebylo založené ani na SLE12-SP1, ani na žádném jiném SLE jádře. O Leapu v pravém slova smyslu se dá podle mne mluvit až od 42.2.

[Zoufalec]

Related: Battle testing data integrity verification with ZFS, Btrfs and mdadm+dm-integrity

[Peter Golis]

Zaujímavý test RAID-5 (RAID-Z) s len troma diskami.

[Josef Kufner]

Jedna otázka je stabilita a spolehlivost filesystému jako takového a druhá otázka jsou schopnosti opravných nástrojů, když se filesystém podělá (ať už svou vinou nebo hardwarovým problémem).

[pavele]

Škoda že Red Hat odpískal btrfs.

Chápu, že vyžaduje předvídatelné chování fs pro příštích několik dekád, ale Stratis podle mne skončí s CentOS 8.

Mohl aspoň pomoci s vývojem. Asi nejsou lidi, javaskript spytlíkuje každý, ale vývoj fs je asi jiná liga.

Používám třeba virtuální disk s xfs, protože umí kvoty na adresář a někteří uživatelé jsou schopni zaplnit jakékoliv množství na disku, i kdyby to byly PB.

Pokud bych se rozhodl pro btrfs, nevím, jaké distro bych zvolil. Fedora má životnost měsíce, Debian má zastaralou verzi, unstable není stable, Arch na server ne (nemám čas), SUSE peklo s Microsoftem a připadá mi, že se specializují na bezpečnostní otázky. Ještě jsem tu nenašel blog "Používám na firemním serveru xx let btrfs na distru yy s takovými zkušenostmi: ..."

[j]

Nastroj na opravovani FS se jmenuje zaloha. A to prekvapive odjakziva.

---

Dete s tim guuglem dopice!

[vencour]

Jak ten čas letí, už v létě 2017 jsem si všiml ...

Btrfs has been deprecated
The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6.
Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux.
The Btrfs file system did receive numerous updates from the upstream in Red Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise Linux 7 series. However, this is the last planned update to this feature.

Takže pokud potřebujete placenou podporu pro aplikaci v RHELu, tak vám to zpravidla s BTRFS a od verze 8 odmítnou uznat.