Názory k článku
Naučte se efektivně používat souborový systém BTRFS (školení)

Obávám se, že jak provozovat RAID1 na jednom disku, nevymysleli a nevymyslí autoři BTRFS ani nikdo jiný.

Tahle vaše historka se dá něčím doložit, nebo jste si jí vymyslel? Pokud já vím, btrfs funguje jinak. btrfs nedovolí v normálním režimu připojit souborový systém, který nesplňuje pravidla daná administrátorem – takže například nepovolí připojit souborový systém s nastavením RAID1, pokud je k dispozici jenom jeden funkční disk. Protože na jednom disku prostě RAID1 nelze provozovat, požadavky správce tedy nejde splnit. Správce to tedy musí vyřešit, a má dvě možnosti – buď doplní disk, aby byly splněny podmínky pro provoz RAID1, nebo určí, že souborový systém má být v režimu single, tedy stačí, když existuje jen jedna kopie každého datového bloku. Pokud vám vadí, že u jiných RAID systémů se automaticky zvolí druhá varianta a správce je o tom jen informován někde v logu, zatímco u BTRFS to musí správce aktivně zvolit, je to váš problém.

Patrně se vám to plete s degraded režimem připojení souborového systému, což je opět vědomý zásah administrátora, který souborový systém připojí ve speciálním režimu umožňujícím opravu RAIDu, který nesplňuje zadaná pravidla. Asi není úplně šťastný ten název „degraded“, protože se to evidentně lidem plete s degradovaným RAIDem z jiných systémů. Tohle je spíš administrátorský režim, podobný třeba single-user režimu linuxových distribucí. Připojit BTRFS v tomto režimu bylo dříve možné jen jednou, aby se tím podtrhlo to, že jde o speciální administrátorský režim, který slouží jen k opravě problému, ne k běžnému provozu. Dnes už toto omezení pokud vím neplatí, lidé zřejmě rádi provozují souborový systém v režimu opravy v běžném provozu, jako by se nic nedělo.

Tam je ale řeč o přimountování BTRFS v servisním režimu ( -o degraded). To je právě to, na co jsem vás už několikrát upozorňoval, že různě mícháte havárii disku, restart počítače, přimountování v servisním režimu – každé je to něco jiného, chová se to jinak, a vy to navzájem volně zaměňujete.

Muzete to obhajovat jak chcete
Proč mi to podsouváte? Já jsem pouze vyvracel vaše bludy pramenící v lepším případě z toho, že nerozlišujete různé provozní stavy souborového systému.

tohle je proste facepalm
Souhlasím. Když si uvědomím, jaká posloupnost kroků musí proběhnout, aby k tomu došlo, věděl bych i adresáta toho facepalmu. Bral bych to jako takové mírné varování pro dotyčného správce, že tentokrát skončil jenom se souborovým systémem v read-only režimu, ale pořád má všechna data – ale když bude dělat takové vylomeniny, příště může dopadnout hůř.

Filip Jirsák 23.08 11:49
u jiných RAID systémů se automaticky zvolí druhá varianta a správce je o tom jen informován někde v logu

uz ponekolikate opakujes toto, ackoliv si byl upozornen ze to je lez, proc umyslne lzes?
mdadm ve vychozim nastavani ma nastaven email monitoring, tedy kdyz vypadne disk a raid se prepne do degradovaneho rezimu, jsem o tom behem nekolika vterin informovan emailem...

Jaká lež? Mdadm automaticky přepne do režimu bez redundance (data jsou jenom na jednom disku), a správce je o tom jenom informován. Nezáleží na rozhodnutí správce, jaký způsob řešení zvolí, prostě jenom dostane informaci. Jestli je ta informace v logu, monitoringu nebo v e-mailu je v kontextu diskuse úplně jedno, podstatné je, že rozhodnutí nedělá správce, je o něm jenom informován.

@Filip Jirsak Jestli je ta informace v logu, monitoringu nebo v e-mailu je v kontextu diskuse úplně jedno,
to neni jedno, je to velky rozdil oproti tomu co si psal predtim:
správce je o tom jen informován někde v logu
rozdil je v tom ze pres vychozi email notify u mdadm se o tom dozvim okamzite... ze zrovna ty s uchylkou na slovickareni ignorujes tento rozdil...

edit:Tato cast nemela byt v citaci:
rozdil je v tom ze pres vychozi email notify u mdadm se o tom dozvim okamzite... ze zrovna ty s uchylkou na slovickareni ignorujes tento rozdil...

Zatímco když se to zapíše do logu, ten slízne monitoring a pošle to na e-mail, takže se to dozvím okamžitě. Já tedy mezi „okamžitě e-mailem“ a „okamžitě e-mailem“ žádný rozdíl nevidím. Podstatné na tom sdělení ale vůbec nebylo to, kdy a jak se to dozvím, ale to, že se jenom dozvím výsledek, ale to rozhodnutí už za mne udělali tvůrci toho RAID systému. V případě BTRFS je naopak na správci, jestli se rozhodne to řešit snížením nároků na duplikaci dat tak, aby to šlo splnit se současným počtem disků, nebo zda vymění nebo přidá disky, aby bylo možné zachovat požadované nároky.

nevim co resis ty, ale ja reagoval na tve o mdadm:
správce je o tom jen informován někde v logu
coz je lez, protoze spravce se to od mdadm v jeho vychozim nastaveni dozvi okamzite z emailu

pokud by spravce mdadm chtel z nejakeho podivneho duvodu nesmyslne pri restartu nebo pri rucnim sestaveni nepovolit automaticke sestaveni pole pokud by melo vypadlej disk, staci pridat parametr: --no-degraded

ovsem povazuju za normalni/vhodne, aby pri vypadku disku z raid1 bylo pole nadale provozuschopne, pripojene a to v rezimu rw, spravce je o stavu informovan okamzite a nez vymeni disk (pokud nema spare disk kdy se to resi automaticky) tak i v pripade (ne/)planovaneho restartu ma stale k dispozici degradovany raid1 v rezimu zapisu...

to ze slovickaris o tom ze "degradovany raid1" nesplnuje to aby data byla na 2 diskach, je jen uchylka, "degradovany raid1" je raid1 v degradovanem rezimu, nestane se z toho najednou kvuli Jirsakovi non-raid disk, nezmizi lusknutim (Jirsakova) prstu z disku mdadm/raid metadata, proste jde o raid1 v degradovanem rezimu a muzes se stavet na hlavu, nic s tim neudelas ;-)

coz je lez, protoze spravce se to od mdadm v jeho vychozim nastaveni dozvi okamzite z emailu

To není pravda, protože mdadm nemá křišťálovou kouli a nevím, kam (a přes co) má ty emaily posílat. Výchozí nastavení (alespoň v debianu) je root. Root může být přesměrován v aliases na reálný email, ale ten tam musí někdo nastavit a musí fungovat lokální smtp server, který je schopný to odeslat na příslušný email admina.

Jinými slovy, dostat email od mdadm není rozhodně nic automatického, naopak je potřeba to nastavit a otestovat.

Navíc ne všechny servery musejí mít nutně schopnost odeslat email a mdadm, stejně jako btrfs, je potřeba monitorovat jinak.

ovsem povazuju za normalni/vhodne

Já považuji za vhodné, aby si lidé přečetli návod k tomu s čím pracují a co si dávají na servery. Už od roku 2011 čtu diskuse o tom, co si dotyčný o btrfs myslel a ono je to přitom jinak a může za to btrfs.

Btrfs, stejně jako všechno ostatní na tomto světě, má nějaké vlastnosti a je potřeba o nich vědět a připravit se na ně. Chování při ztrátě redundance je jeden z těchto aspektů. To, že jiné projekty řeší redundanci a její ztrátu jinak neznamená, že je to tak správně.

@Tomas Crhonek 24.8 14:56
není pravda, protože mdadm nemá křišťálovou kouli a nevím, kam (a přes co) má ty emaily posílat. Výchozí nastavení (alespoň v debianu) je root.

je to pravda, mdadm to automaticky posila na mail, ze je vychozi root je irelevantni, pokud to nekomu nevyhovuje muze si mail na ktery mdadm posila zmenit...
to ze spravce musi mit zprovoznene odesilani mailu je take irelevantni, protoze to jiz davno ma zprovoznene i kdyby mdadm nepouzival, je to jako bys psal ze nelze spusit mdadm protoze neni nainstalovana libc, ze nelze nainstalovat libc protoze neni nainstalovane Linux jadro ;-)

Já považuji za vhodné, aby si lidé přečetli návod k tomu s čím pracují
pokud si prectu navod dozvim (nebo v minulosti dozvedel) ze raid1 bude pri degradovanem rezimu mozne pripojit automaticky i po restartu, pri neplanovanem vypadku atd? pokud ne, je to v rozporu s tim co sem psal ze povazuji za normalni/vhodne ;-)

S tímhle postupem ale nebyl problém nikdy. To je právě ono, že kkt1 vůbec netuší, jak vypadal ten problematický případ, ale o to víc si o tom neustále vymýšlí.

Já tvrdím, že ten problém, o kterém je celou dobu řeč, byl v tom, že ve speciálním administrátorském režimu určeném pro vyřešení situace, kdy počet disků neumožňuje splnit pravidla RAIDu definovaná správce, bylo možné souborový systém připojit pouze jednou. Pokud správce tento režim nevyužil k nápravě (buď přidání disku nebo zmírnění pravidel RAIDu, např. převod na režim single) – v drtivé většině známých případů proto, že na to kašlal a nevěděl, k čemu ten režim slouží, teoreticky k tomu mohlo dojít ale třeba i kvůli výpadku napájení a restartu počítače během řešení – nemohl znovu připojit souborový systém v tomto speciálním administrátorském režimu, nemohl souborový systém připojit ani v běžném režimu zápisu (protože nebylo možné splnit definovaná pravidla, např. že každý blok bude zapsán alespoň na dva disky), takže zbyla jen možnost disk připojit v režimu pouze pro čtení.

Ale klidně se s námi můžete podělit a svůj názor na to, v čem byl problém. Zejména bude zajímavá ta část, jak to, že drtivá většina lidí, kterým odešel disk v dvoudiskovém BTRFS RAID1, prostě vyměnila disk nebo snížila RAID na režim single a dál bez problémů s BTRFS fungují.

z odkazu:
"However, it is known that Btrfs RAID is unstable and not suitable for production environments.
For this reason, Synology chose Linux RAID over Btrfs RAID"

asi by jim to mel jit Jirsak vysvetlit ;-)

ackoliv chapu ze minusari jsou specificky druh, co se vam nelibi na citaci z predchoziho odkazu? kontaktujte Synology pokud mate pupinky z toho co na svych strankach o BTRFS pisou ;-)

Mě by jen zajímalo, čeho těmito komentáři chceš dosáhnout. Myslíš, že lidi přestanou používat to co jim vyhovuje jen proto, že to někdo napsal na fórum? Urážkami?

Je skvělé, že v linuxu máme na výběr a každý admin si může vybrat FS podle situace i podle toho, co mu víc vyhovuje. Na každé nasazení se hodí něco jiného. Pokud se mě někdo zeptá na moje osmileté zkušenosti s provozem BTRFS, rád mu je bez obalu sdělím, případně odkážu na vlastní web. Nikomu nic nenutím, jen předávám informace.

Ono totiž, nic na světě není dokonalé. I ty zmíněné md lvm ext4 zfs mají svá zákoutí, o kterých je dobré vědět. LVM sice podporuje snapshoty, ale jejich merge trvá neůměrně dlouho a navíc to LV nelze používat (celkem logicky). ext4 například nemá (stejně jako všechny fs staré generace) checksum dat. md neví, které bloky jsou zapsané a při synchronizaci dělá celý blok device, na kterém může být jen pár GB dat. zfs neumělo do letošního roku odebrat vdev (už to umí, ale je to zatím jen pro opravu konfigurace; už je to i ve FreeBSD 11.2) nebo například nelze smazat dataset, pokud má nějaké snapshoty nebo clony.

Pokud něco z toho admin dopředu neví, tak se může dostat do velmi nelehké situace při použití kteréhokoliv z těchto systémů.

Jinak check ani balance skutečně potřeba není. Balance se postupně integruje do btrfs (podobně jako v minulosti například autovacuum u postgresql) a patrně zůstane jen pro konvert různých typů redundace, a check u ostatních fs zkontroluje stejně jen integritu samotného fs, ale o datech stejně nic nevíte. Od toho jsou checksumy. Tzn pokud je disk nabořený (a smart třeba mlčí), tak to stejně poznáte v logu nebo ve stats. Ono totiž je mnohem pravděpodobnější, že se dřív naboří data, než struktura fs.

Topick z roku 2008? Jaký to má smysl ? Synology také dnes používá EXT4 a ne EXT3

JJ, protože na všech ostatních FS se dělá check pravidelně ;-).

Takže reality check. Některé distribuce už hodně dávno (2008) vypnuly pravidelnou kontrolu ext3 (počet připojení / čas od posledního checku) a spoléhaly se jen na nalezení chyby během provozu (potom nastavily flag pro check během dalšího přípojení). Ext4 bylo upraveno tak, že se check (po chybě) dělal jen na oblasti, která byla používaná, protože check celého FS zvláště u velkých polí trvá fakt dlouho. fsck.xfs vracel automaticky jen nulu, tj během mountování při bootu i při nastavení flagu ve fstabu prostě nic nekontroloval.

Takže většina i starých fs se na pravidelný (pokud jej tedy měly, krom extX snad nikdo) check vyflákla a stačí jim jen check během mountování, kdy driver posoudí stav.

Půjde to udělat a budete mít k dispozici 1 TB. Když pak ten 1 TB disk vyměníte za 2 TB, budete mít pro data 2 TB, když místo toho přidáte další 2 TB disk, budete mít 3 TB atd. Nebo třeba můžete k tomu 12 TB disku dát 12 jednoterových disků a budete mít 12 TB. Prostě je to flexibilní a BTRFS využije dostupné disky a zařídí, aby každý datový blok byl uložen alespoň na dvou z nich.

v tvem druhem a dalsim prikladu jiz nepujde o RAID1, protoze vsechna data nebudou mirrorovana na vsechny disky, coz je podstata RAID1

Tady ovšem není řeč o (obecném) RAID1, ale o BTRFS RAID1, což je něco jiného, než (obecný) RAID1. Plyšového medvěda v hračkářství se přece taky nebojíte, i když je součástí jeho pojmenování „medvěd“, ne?

pokud je rec o RAID1 tak nemis byt demagog aby si pouzival termin jako "obecny", protoze RAID1 je RAID1, nic jako obecny neexistuje...
"BTRFS RAID1" znamena (v pripade NEpouziti RAID1) ze BTRFS nepouzije RAID1 i presto ze tomu RAID1 rika... pokud by BTRFS zacalo rikat manualovym strankam "BTRFS Filesystem" znamena to ze je to Filesystem nebo ze pojmenovana neco spatne?

Myslel jsem si, že rozdíl mezi „medvěd“ a „plyšový medvěd“ chápou i malé děti, takže to na tom příkladu musí pochopit každý. Vždycky zapomenu, že není dobré hlupáky v jejich schopnostech přeceňovat.

Tady je ovšem celou dobu řeč o BTRFS RAID1. O (obecném) RAID1 v tomto vlákně píšete jenom vy.

taky je rec o tom ze RAID1 je jenom 1, opakovanim toho ze BTRFS rika RAID1 necemu co NENI RAID1 z toho pravdu neudelas...

Tohle je RAID1: https://cs.wikipedia.org/wiki/RAID#/media/File:RAID_1.svg

Cokoliv jineho NENI RAID1, tedy BTRFS RAID1 je ve zkutecnosti RAID1E:
https://en.wikipedia.org/wiki/Non-standard_RAID_levels#/media/File:RAID_1E.png