Ars Technica: pohled na Btrfs, věčně nedodělaný linuxový souborový systém

Jim Salter na webu Ars Technica ve stručnosti shrnuje vlastnosti souborového systému Btrfs ve srovnání s alternativami (OpenZFS, mdraid+LVM+ext4) a ve zbytku článku varuje před jeho implementací RAID. V navazujících textech se plánuje věnovat dalším funkcím Btrfs.

28.9.2021 08:00 | Fluttershy, yay! | Zajímavý článek

Komentáře

[trekker.dk]

To s tím RAIDem pěkně popisuje, jak (ne)příčetný musel být ten, kdo to vymejšlel.

[R]

Uz chapem, preco Synology pouziva btrfs nad LVM.

Chcel som vyskusat btrfs na fileserver kvoli automatickemu zalohovaniu starsich verzii suborov. Server ma nastastie HW RAID. Ale ak je cele btrfs tak chore ako ten jeho RAID, tak to radsej skusat nebudem.

[Heron]

Není. Tohle jsou jen nářky lidí, kteří se nenamáhali si o tom zjistit něco víc a stále trvají na srovnávání s něčím minulým. btrfs poskytuje skvělé služby pro ty, kteří je mají kde využít a samozřejmě, jako všechno, má svoje quirky. Stejně jako každý jiný fs. Podobný článek by šel napsat o čemkoliv. Zrovna pro verzování (velkých) binárních souborů neznám nic lepšího.

[GeorgeWH]

Ale je. Pokial mi sa RAID1|10|5|6|... zkliaga po zlyhani jedneho disku, tak je to nepouzitelna chujovina. Pretoze RAID nasadzujem prave preto, aby mi pri zlyhani jedneho (a viac) diskov system fungoval dalej.

[Heron]

Ten FS neselže. Jen se v případě výpadku disku chová jinak, než některé jiné systémy. To je celé.

Pretoze RAID nasadzujem prave preto, aby mi pri zlyhani jedneho (a viac) diskov system fungoval dalej.

To je naprosto v pořádku, ale jsou i jiná využití FS. Třeba já si nemůžu vynachválit vlastnost snadného odebrání disku (a tím zmenšení velikosti fs). Takto jsem za plného chodu serveru s pomocí pouze jednoho dalšího disku přestěhoval storage na jiný server. Tam, kde je potřeba víc místa, se disk přidá a tam, kde je místa dost, se zase odebere. Tohle je vlastnost, kterou nic jiného nemá (rozhodně ne takto flexibilní).

Se selháním disku za běhu jsem se ještě nesetkal. Většinou to dostatečně brzo hlásí smart. Tj u btrfs jsem tento problém nikdy nemusel řešit, zato mi pomohl vyřešit spoustu jiných situací. A ano, smart není všespásný, takže když budu muset jednou za x let řešit degraded btrfs, tak se z toho nezblázním.

[luky]

Takto jsem za plného chodu serveru s pomocí pouze jednoho dalšího disku přestěhoval storage na jiný server. Tam, kde je potřeba víc místa, se disk přidá a tam, kde je místa dost, se zase odebere. Tohle je vlastnost, kterou nic jiného nemá (rozhodně ne takto flexibilní).

Pred temer 20 lety jsem podobne prestehoval storage zalozenou na mdraidu a ext2 za pomoci network block device. Prendal jsem disk do nove masiny a pomoci NBD ho pridal zpet do raidu ve stare masine.

[Aleš Kapica]

Takto jsem za plného chodu serveru s pomocí pouze jednoho dalšího disku přestěhoval storage na jiný server. Tam, kde je potřeba víc místa, se disk přidá a tam, kde je místa dost, se zase odebere. Tohle je vlastnost, kterou nic jiného nemá (rozhodně ne takto flexibilní).

Pred temer 20 lety jsem podobne prestehoval storage zalozenou na mdraidu a ext2 za pomoci network block device. Prendal jsem disk do nove masiny a pomoci NBD ho pridal zpet do raidu ve stare masine.

Tak tomu se říká blažená nevědomost…

[cezz]

Ja osobne vnimam fakt ze sa FS chova inak a prekvapivo bez nejakeho dobreho dovodu aby to tak bolo ako dost vyrazne negativum. Pokial clovek neriesi tieto problemy pravidelne, je celkom jednoduche nedopatrenim prist o data, alebo sposobit downtime. (rad sa necham poucit preco to BTRFS robi prave takto, nemam osobne moc skusenost)

Co sa tyka toho odobrania disku, OpenZFS uz toto dokaze, aj ked mozno nie tak flexibilne ako BTRFS. Na tvoj konkretny priklad by sa to pouzit dalo, aj ked OpenZFS ma na to omnoho vhodnejsi zfs send.

Co sa tyka toho, ze co kto potrebuje, pride mi tvoja situacia trochu prekvapiva, lebo stahovanie dat medzi servermi pri ktorom potrebujes odoberat disky mi pride ako velmi vynimocna situacia. V enterprise sfere urcite, v domacom pouziti minimalne velmi nezvycajne.

Naproti tomu zlyhavajuce disky su popri zlyhavajucom zdroji asi najbeznejsi failure mod na beznom HW. Z vlastnej skusenosti v profesionalnej sfere disky zlyhavaju neustale a casto bez predchadzajuceho varovania. (v tomto smere som hlavne SSD videl zlyhat bez akehokolvek varovania asi castejsie ako pripady kedy dopredu hlasil nejake problemy cez SMART) V domacom nasadeni mam pool ktory za tie roky nema ani jeden povodny disk - niektore dopredu vykazovali zle SMART parametre - niektore dokonca v dostatocnom predstihu aby som ich vymenil pred uplnym zlyhanim. Ale niektore zlyhali potichu alebo ten cas nebol dostatocny na to aby som stihol vymenu vcas. (zvlast v domacom prostredi nezvyknem mat nahradne disky k dispozicii hned a nejaky ten den trva nez ich zozeniem)

[Heron]

rad sa necham poucit preco to BTRFS robi prave takto

Já ten důvod neznám a nikdy jsem po tom neměl potřebu pátrat. Četl jsem důvod (nikoliv od autorů btrfs, ale někde v diskusi), že program se má chovat tak, že jednoznačných způsobem ohlásí chybu, pokud nelze splnit podmínky pro svůj běh. (A s tímto nelze než souhlasit. Kéž by se všechny programy chovali takto a nastavovali nenulovou návratovou hodnotu.) Tedy v případě, že btrfs nemůže splnit požadovanou redundanci, tak se zkrátka nepřimountuje (bez dalšího parametru). Z tohoto pohledu to není špatně, prostě admin požaduje fs s jistou reduncancí, takto jej nastavil a ten fs nemůže jen tak namountovat bez splnění této adminem nastavené redundace, takže od něj očekává nějakou akci.

OpenZFS uz toto dokaze, aj ked mozno nie tak flexibilne ako BTRFS.

Ano, od roku 2018. Tehdy se to doporučovalo pouze jako náprava chyby admina, kdy tam připojí device, které nechce. Funguje to tak, že zfs neumí odebrat vdev z poolu, tak prostě udělá nějaký interní, kam ten odstraňovaný vdev přesune. A na ten interní vdev už potom nezapisuje, jen čte a maže. Ale je to info z 2018.

Co sa tyka toho, ze co kto potrebuje, pride mi tvoja situacia trochu prekvapiva, lebo stahovanie dat medzi servermi pri ktorom potrebujes odoberat disky mi pride ako velmi vynimocna situacia. V enterprise sfere urcite, v domacom pouziti minimalne velmi nezvycajne.

V enterprise světě máme disková pole, tam se vůbec o btrfs, zfs, mdadm apod nemusíme bavit. Tj co je vlastně hlavní doména těchto systémů? Levné instalace, kde není skutečný HW raid, kde není dost disků apod. Proto se nasazuje mdadm, ušetří se za HW raid (skutečný). Proto se nasazují zfs nebo btrfs, jak levná lepší náhrada mdadm. Proto dává smysl šetřit za disky. Ano, je lepší koupit celé kompletně osazené diskové pole a ten starý server jen přesunout. Jenže ne vždy je to ekonomicky únosné. A co potom s tím starým polem? Takže dává perfektní smysl v těchto levných prostředích nasadit btrfs / zfs a využít je k provozu.

A to, že je to "nezvyklé" je dáno tím, že spousta adminů tyto systémy ani nezná. Jedou si to svoje, mdadm, ext4. A pokud už to znají, tak k tomu přistupují jako ke starým systémům (je to často cítit i z těch článků). Tj nenapadne je, že mohou plně využít flexibility, kterou jim to nabízí. V tom diskovém poli se dají uplatnil různé velikosti disků a postupně je vyměnovat za větší. A fs tak v čase postupně poroste.

OpenZFS ma na to omnoho vhodnejsi zfs send

btrfs má také send, jak myslíš, že jsem to dělal? Hezky přesouvat subvolume za subvolume.

Naproti tomu zlyhavajuce disky su popri zlyhavajucom zdroji asi najbeznejsi failure mod na beznom HW.

Ano, to je pravda, jednou nám odešlo 6 disků v jednom poli skoro současně (15k rpm 600GB, takže resilvering jenoho disku krásných 20minut).

V domacom nasadeni mam pool ktory za tie roky nema ani jeden povodny disk - niektore dopredu vykazovali zle SMART parametre - niektore dokonca v dostatocnom predstihu aby som ich vymenil pred uplnym zlyhanim.

Ano, já taky, v tom btrfs z roku 2010 mám už třetí nebo čtvrtou generaci disků. Ještě se to nepotkalo s nějakým okamžitým selhnáním, ale tam bych degraded mount přežil.

(zvlast v domacom prostredi nezvyknem mat nahradne disky k dispozicii hned a nejaky ten den trva nez ich zozeniem)

To já jsem si na to zvykl všude. Je lepší mít disk na poličce, než ho tam nemít. V serverovém provozu pochopitelně i jeden celý záložní server + disky a zdroje. (I když zdroje nám neodcházely tak často.)

[j]

Prave ze v ent se uz HW pole peknych par let nepouzivaji. Ve skutecnosti mas v ty krabici celkem normalni PC, a v nem SW. Kterej minimalne z pohledu administrace svoji funcionalitou velmi pripomina prave btrfs.

Par takovych policek adminuju, a narozdil od dob drivejsich, kdy si trebas na rozsireni pole potreboval pridat celou raidgrupu, takze typicky minimalne 5 disku, muzes dneska disk pridat klidne jeden, a muzes ho klidne i odebrat, a muzes rict, ze volumeX bude jakoze raid5 a volumeY jakoze raid 10 ... a kdyz si casem vzpomenes, muzes to zmenit. Zaroven uz neplati, ze by volume byl nejak navazanej na fyzicky disky, proste reknes jeho velikost a pole si to nejak prechroupe, pripadne mu muzes rict, ze ma byt na nejaky skupine disku - jako ze tohle na ssd, tamto na hdd ... ale neurcujes konkretni raidy ke kterym patri.

---

Dete s tim guuglem dopice!

[Heron]

Prave ze v ent se uz HW pole peknych par let nepouzivaji.

Ale já jsem nikde nenapsal, že se používají. (Navíc tuhle debatu už jsme několikrát vedli, ne?)

Kterej minimalne z pohledu administrace svoji funcionalitou velmi pripomina prave btrfs.

No mě by celkem zajímalo, co tam je, protože ono to nápadně připomíná víc věcí a bylo by celkem dobrý se podívat na zoubek třeba na licence, jestli náhodou nám tu někdo neloupe GPL2 perníček.

[GeorgeWH]

Já ten důvod neznám a nikdy jsem po tom neměl potřebu pátrat. Četl jsem důvod (nikoliv od autorů btrfs, ale někde v diskusi), že program se má chovat tak, že jednoznačných způsobem ohlásí chybu, pokud nelze splnit podmínky pro svůj běh. (A s tímto nelze než souhlasit. Kéž by se všechny programy chovali takto a nastavovali nenulovou návratovou hodnotu.) Tedy v případě, že btrfs nemůže splnit požadovanou redundanci, tak se zkrátka nepřimountuje (bez dalšího parametru). Z tohoto pohledu to není špatně, prostě admin požaduje fs s jistou reduncancí, takto jej nastavil a ten fs nemůže jen tak namountovat bez splnění této adminem nastavené redundace, takže od něj očekává nějakou akci.

Cize len potvrdzjes, ze je to chujovina. 99% nasadzovania RAIDu (redudantneho) je HA. HA v zmysle, ze si system bezi bez vypadku aj v pripade zlyhania disku/diskov. A to je ta pozadovana funkcionalita FS - udrzat system pri zivote. Nie, jeho ulohou nie je zachovat data, na to su zalohy. A ze mi este FS bude kecat do toho, ci si ho mozem pripojit, alebo nie (v pripade, ze je konzistentny, nema chyby a pod.) - tak urcite.

[cezz]

Nechce sa mi teraz dohladavat nejake historicke dovody preco to tak je, ale pripada mi ze proste niekto nechcel aktualne riesit nejake API a CLI na spravu BTRFS tak to nejak nalepili na sucasne utility a to presne vedie k tomuto dost nestandardnemu spravaniu. Podla mna to poukazuje proste na fakt, ze BTRFS este potrebuje kus vyvoja ako v jadre tak v userspace.

Asi sa to v mnozstve pripadov da pouzivat aj taketo, ale ta kritika v tom clanku podla mna ma zmysel. V mnohych ohladoch je to dost tazka beta.

[cezz]

program se má chovat tak, že jednoznačných způsobem ohlásí chybu, pokud nelze splnit podmínky pro svůj běh

Toto je zaujimavy argument. Ono mozno je prekvapive to, ze zatial co klasicky FS ked spustas mount tak sa bud pripojit da alebo neda, lebo neriesi tu blokovu vrstvu pod tym. BTRFS toto riesi a teda sa v tomto pripade moze spravat inak.

Mozno by som argumentoval ze ked spustam prikaz mount, chcem primarne ten filesystem pripojit a filesystem je v stave kedy sa toto spravit da. Ano, je v degraded stave, ale to podla mna na tejto urovni nema zmysel riesit. Uz len samotny fakt, ze mount nema mechanizmus akym by vratilo zmysluplny error message mi pripada ako dobre znamenie ze to nie je to spravne miesto kde by malo BTRFS skumat redundanciu.

To uz mi pride lepsie ako to riesi ZFS (a svojim sposobom aj LVM), ktore mount v podstate uplne obchadza a ma na to svoje vlastne CLI.

Vseobecne mi cela tato snaha BTRFS namapovat funkcionalitu na existujuce struktury (spominany mount, ktory zlyha pre degradovane pole, alebo pripajanie prostrednictvom referencie na jeden z fyzickych diskov) pripada dost nestastna, lebo proste spaja dva dost odlisne koncepty. Samozrejme ze sa potom prejavi to ze to spravanie je velmi prekvapujuce a nepride mi velmi korektne tvrdit ze sa "len v pripade vypadku chova inak nez niektore ine systemy" - ako ano je to pravda, chova sa inak a chova sa velmi nestandardne a zrejme prave preto, ze sa snazi prezentovat pouzivatelovi cez interface ktory na to nie je urceny.

Napriklad swap sa bezne nastavuje v /etc/fstab s inymi FS, ale ma svoje vlastne swapon/swapoff namiesto toho aby sa nejako snazili ohnut mount na pripajanie swapu cez nejake mount -t swap /dev/sdx /this/path/is/ignored alebo nieco podobne.

[Heron]

Ono mozno je prekvapive to, ze zatial co klasicky FS ked spustas mount tak sa bud pripojit da alebo neda

Toto vůbec není pravda, proto je ve fstabu sloupeček pass, který říká v jakém pořadí a jestli vůbec se má na fs spouštět fsck. A viděl jsem spoustu rozbitých FS, u kterých mount prošel, rychlý fsck při startu také, ale kompletní fsck ne. Jenže od toho se ustoupilo v rámci rychlosti bootu. A aby toho maléru nebylo málo, tak ještě se mountuje s parametry continue nebo readonly. Dřív bylo zvykem při chybě pěkně zpanikařit.

Uz len samotny fakt, ze mount nema mechanizmus akym by vratilo zmysluplny error message mi pripada ako dobre znamenie ze to nie je to spravne miesto kde by malo BTRFS skumat redundanciu.

Já to vidím opačně. Právě proto, že nemá pořádný mechanismus pro error message, tak ten mount na degradovaném fs nemá projít. Aby bylo naprosto jasné, že se něco děje.*

U toho zfs i mdadm to s klidem najede i do degradovaného stavu a vůbec nic neindikuje nějaký problém. Ano, můžeme říct, že tam má být řádný monitoring nebo se má admin alespoň podívat do zpool status, ale kdo to dělá, že jo a ten monitoring je další vrstva navíc, která musí být nastavena a klidně i tam může být chyba.

To že by btrfs mohl mít vlastní toolset i pro mount, klidně, souhlas. Ono to spíš ukazuje na nepříliš vyhovující stav mount jako takového. Přes parametry mountu se u některých fs (JFS) třeba i ten fs zvětšuje. A ještě admini (ne)očekávají další chování. Podle mě třeba do mountu vůbec nepatří compress, protože to se má nastavit v tom fs, třeba pro jednotlivé subvolumy zvlášť. Atd.

Napriklad swap sa bezne nastavuje v /etc/fstab s inymi FS

Další ukázka toho, že to tam nepatří. Dělají se výjimky pro síťové FS, pro pseudofs (devfs, procfs), pro výměnná média a pro swap. Sranda je, že na FreeBSD mám fstab zcela prázdný (protože zfs) a na linuxu tam mám jen /, protože zbytek je v systemd. Zdá se, že tento soubor se už nějak přežil.

*) Já mám obecně rád tvrdá selhání, protože to potom vede k opravě, zatímco skrývání chyb velmi často k poškození dat. Jeden starý příběh ze světa MySQL.

[cezz]

Toto vůbec není pravda, proto je ve fstabu sloupeček pass, který říká v jakém pořadí a jestli vůbec se má na fs spouštět fsck.

Myslim, ze tu je dost dolezite to brat v kontexte a docitat moju vetu dokonca:

Ono mozno je prekvapive to, ze zatial co klasicky FS ked spustas mount tak sa bud pripojit da alebo neda, lebo neriesi tu blokovu vrstvu pod tym.

fsck neriesi blokovu vrstvu, riesi iba korektnost daneho filesystemu. Ked budes mat ext4 na mdraid, tak fsck nehodi error lebo raid ma znizenu redundanciu. To ci je realne filesystem poskodeny alebo nie tiez velmi nesuvisi s redundanciou. BTRFS moze kludne nastartovat s oboma diskami a napriek tomu drzat poskodene data. (inak by nebolo treba scrub)

Dřív bylo zvykem při chybě pěkně zpanikařit.

Osobne nepoznam jediny RAID system ktory by pri znizenej redundancii nenastartoval alebo dokonca vyhodil panic.

Aby bylo naprosto jasné, že se něco děje.

Ano, můžeme říct, že tam má být řádný monitoring

Sam si si odpovedal, na to tu mame monitoring. Ja ked vidim ako v SMART statistikach rastie Reallocated Sectors Count, tak predpokladam ze disk ide umriet a planujem co najskorsiu vymenu. Inak povedane nieco sa deje. Ale ak by mi koli tomu nepresiel mount, tak asi tomu disku aj s celym filesystemom pomozem kladivom.

ale kdo to dělá, že jo

Kazdy komu zalezi na tom systeme.

a ten monitoring je další vrstva navíc, která musí být nastavena a klidně i tam může být chyba

Ten monitoring tam musi byt tak ci tak. To ze ta BTRFS "upozorni" pri mounte ze je znizena redundancia by som asi tazko povazoval za relevantny sposob ako sa dozvediet ze odisiel disk. (zvlast ked je ten error message uplne zavadzajuci) Ten moze zlyhat kedykolvek po pripojeni a ty sa o tom dozvies kedy? Pri najblizsom reboote?

Ono to spíš ukazuje na nepříliš vyhovující stav mount jako takového.

Ja by som to skor videl tak, ze mount robi presne to co ma. Ak to chcu ludia pouzivat na spravu BTRFS, tak by podla mna mali mount rozsirit tak aby to davalo zmysel.

Další ukázka toho, že to tam nepatří. Dělají se výjimky pro síťové FS, pro pseudofs (devfs, procfs), pro výměnná média a pro swap.

V tomto suhlas. Ja tak nejak nemam pocit ze tam ten swap patri, ale historicky to tak bolo - predpokladam ze sa niekomu v 90-tych rokoch nechcelo pridat nejaky /etc/swapconfig alebo nieco podobne, tak to nalepili na fstab. Ale myslim, ze je pomerne zasadny rozdiel, ze aspon mount upravili a pridali tam tu vynimku. (ze teda vies nastavit mount path na none)

[Heron]

fsck neriesi blokovu vrstvu, riesi iba korektnost daneho filesystemu

No to neřeší, protože o ní nic neví.

Ked budes mat ext4 na mdraid, tak fsck nehodi error lebo raid ma znizenu redundanciu.

Ano, to ani neočekávám, ale ten error by měl hodit mdadm.

BTRFS moze kludne nastartovat s oboma diskami a napriek tomu drzat poskodene data. (inak by nebolo treba scrub)

To jistě může, ale btrfs kontroluje checksum dat při každém čtení a už u toho čtení může opravit vadnou kopii. Tj u btrfs nic jako oddělená bloková vrstva neexistuje.

Sam si si odpovedal, na to tu mame monitoring. Ja ked vidim ako v SMART statistikach rastie Reallocated Sectors Count, tak predpokladam ze disk ide umriet a planujem co najskorsiu vymenu. Inak povedane nieco sa deje. Ale ak by mi koli tomu nepresiel mount, tak asi tomu disku aj s celym filesystemom pomozem kladivom.

Jasně, ale mám spoustu příběhů o tom, jak byl monitoring zcela naprd, o smartu nikdo netušil a ani třeba o tom, že jejich řadič měsíce hlásí vybitou baterku. Právě na základě těchto zkušeností si myslím, že je lepší selhat dřív a explicitně, než to skrývat. Protože až se ta vadná data propíší na všechny zálohy, tak bude pozdě. (Aneb zálohujeme sice pravidelně, ale naprosto vadná data. Viz ta rozpadlá replikace z toho článku.)

[Aleš Kapica]

Jo. Všichni mají plnou hubu keců, jak jim na datech záleží a pak by si nechali pro korunu vrtat koleno, jen aby nemuseli do něčeho investovat. Ta to pak odkládají a odkládají. A nakonec se hrozně diví, když jim to chcípne totálně a data jsou nenávratně v hajzlu.

[cezz]

Ano, to ani neočekávám, ale ten error by měl hodit mdadm.

mdadm samozrejme ukaze ze je degraded.

To jistě může, ale btrfs kontroluje checksum dat při každém čtení a už u toho čtení může opravit vadnou kopii.

Moze opravit vadnu kopiu ak ma kopiu ktora nie je vadna. Proste ten predpoklad, ze mount nevyhodil error a teda pole je v poriadku je podla mna celkovo vadny, lebo je vela failure scenarios kedy mount prebehne a napriek tomu su data ked nie rovno znicene, tak aspon v ohrozeni. Napriklad vypadlo chladenie a disky maju 60C uz pri starte. Mount ti kludne prejde ale z hladiska ochrany dat by bolo lepsie s takym polom nepracovat, disky vypnut a riesit teplotu. Keby clovek monitoroval SMART, tak to najskor aj spravi. Proste zlyhavajuci mount pri degraded rezime riesi tak uzku skupinu problemov, ze to podla mna nestoji za to robit tam nejake nestandardne spravanie.

Tj u btrfs nic jako oddělená bloková vrstva neexistuje.

Presne tak, tak preco ho ma niekto spravovat s nastrojmi ktore nejakym sposobom ocakavaju blokovu vrstvu, alebo sa tvarit ze tam nejaka oddelena blokova vrstva je?

Jasně, ale mám spoustu příběhů o tom, jak byl monitoring zcela naprd, o smartu nikdo netušil a ani třeba o tom, že jejich řadič měsíce hlásí vybitou baterku. Právě na základě těchto zkušeností si myslím, že je lepší selhat dřív a explicitně, než to skrývat.

To iba ukazuje na to, ze zavesit cely monitoring na mount ktory sa deje raz za par mesiacov je nezmysel. Ked ti bude SMART mesiace kricat, ze na disku sa zacinaju objavovat vadne bloky, tak je sice pekne ze az jedneho dna ked ten disk odide a ty restartujes, ze to zlyha explicitne a natvrdo, ale tiez ti moc nepomoze ak sa ukaze ze rovnako krical aj ten druhy disk, akurat neumrel uplne ale sanca ze prezije resilver je nulova. Toto je realny pribeh, ktory som osobne zazil, kedy odisiel v serveri ventilator takym sposobom, ze zacal neumerne vibrovat a postupne znicil jeden disk za druhym a v momente ked prvy disk vypadol z pola, ostatne disky uz neboli v stave prezit resilver. (neslo o mission critical data, ten RAID tam bol v podstate len pre uptime, ale nakoniec utrpel aj ten, kedze uz bolo neskoro nieco hotswappovat) Podla mna podporovat spravanie ze niekto spolieha na zlyhavajuci mount je presne to co ty tvrdis - skryvanie problemov ktore mozu viest k strate dat.

Aneb zálohujeme sice pravidelně, ale naprosto vadná data. Viz ta rozpadlá replikace z toho článku.

Toto je podla mna nieco co by naopak BTRFS uplne explicitne nemalo dovolit a keby v tomto momente zlyhal mount, tak by som mozno aj suhlasil, ze je to tak spravne. Jasne jedna sa v podstate o PEBKAC, ale uprimne ak BTRFS vyhodi error pri pripajani degradovaneho pola, tak sa nebudem cudovat pouzivatelovi ktory povazuje pripojeny filesystem za konzistentny. Nepochybne by na to clovek s dobrym monitoringom prisiel, preto netvrdim ze je to chyba BTRFS, ale to ako je navrhnute spravanie takeho systemu je velmi nestastne.

[Heron]

mdadm samozrejme ukaze ze je degraded

Pouze pokud se na to zeptáš. Ani při bootu neukazuje žádný problém.

Proste ten predpoklad, ze mount nevyhodil error a teda pole je v poriadku je podla mna celkovo vadny

To pole je v pořádku v této chvíli. Tedy v okamžik toho mountu. Že ty disky za 5 minut rozvibruje ventilátor v tuto chvíli nikdo netuší.

Podla mna podporovat spravanie ze niekto spolieha na zlyhavajuci mount je presne to co ty tvrdis - skryvanie problemov ktore mozu viest k strate dat.

To, že se problémy mohou vyskytnout i po té, co mount projde, je snad jasné. To ale neznamená, že ten mount nemá hlásit chybu nikdy. Pokud mount neprojde, tak je to indikace problému, který je potřeba okamžitě řešit. Ano, ten problém mohl být detekován dříve a přehlédnut, ale to neznamená, že ten nástroj má mlčet. Stejně tak se tím neříká, že tam nemá být další monitoring. Má. Ale to neznamená, že některé programy mohou skrývat chyby.

Stejně tak ten příklad s tím mysql po změně konfigurace. Bylo by mnohem lepší, kdyby ta služba nenajela. Tím, že najela bez některých engine přímo způsobila ztrátu dat.

[cezz]

Pouze pokud se na to zeptáš.

Pride mi to ako lepsia alternativa nez vyhodit error pri v podstate nesuvisiacej operacii o par tyzdnov neskor ked nahodou restartuje server.

To ale neznamená, že ten mount nemá hlásit chybu nikdy.

Jediny dovod preco mount hlasi chybu namiesto toho aby pripojil automaticky degraded pole je ten, ze sa BTRFS asi ako jediny RAID system dokaze dostat do stavu kedy sa ten chybajuci disk neskor pripoji a vsetky data co boli medzi tym zapisane budu ohrozene kym clovek rucne nespusti ballance. mdraid v takom pripade robi normalne resilvering, ZFS spravi len resilvering chybajucich zapisov, BTRFS uplne potichu problem ignoruje.

Cize ano, chapem ze asi chces aby taky mount zlyhal, chapem ze nie je dobry napad pridavat -o degraded pri starte aby taky system vzdy nabehol. Ano pri BTRFS to zmysel ma, ale len preto ze ten mirroring nerobi uplne zakladnu kontrolu ci je zostavene pole v poriadku.

[%]

Jakmile začne systém do logu na něco nadávat, například na disk nebo filesystém, tak má administrátor možnost zasáhnout. Pokud to neudělá, je to jeho problém.

Btrfs, pokud zjistí, že něco nepřečetl správně, jak to bylo zapsáno, tak nadává, případně i opraví. Na rozdíl od běžných filesystémů, které na nic nepřijdou. A to, že při rebootu s chybějícím diskem v poli je třeba zadat nějaký parametr jádru, je jenom správně, protože v opačném případě na to administrátoři kašlou a říkají si, naběhlo to, to je dobrý. (Já vím, enterprise, bla bla...)

[GeorgeWH]

A to, že při rebootu s chybějícím diskem v poli je třeba zadat nějaký parametr jádru, je jenom správně, protože v opačném případě na to administrátoři kašlou a říkají si, naběhlo to, to je dobrý. (Já vím, enterprise, bla bla...)

Ale ved toto je uplne irelevantne. To ako keby auto nenastartovalo, kym si nedas pas. Ked je niekto dement, tak nech si ten pas nedava (analogicky admin nereaguje na hlasky systemu), ale preco by ma malo toto obmedzovat, ked len potrebujem preparkovat auto o 3m dalej? Pricetny admin si systemy sleduje a adekvatne reaguje. To akoze teraz budeme vsetky aplikacie robit ako pre debilov a budu za nas "riesit" problemy? HW a SW ma robit to, co chcem ja a co uznam za vhodne (tu je asi problem "nestandardne" spravanie sa btrfs oproti ostatnym implementaciam RAID-u). Nasledky preberam ja. Maximalne ma ma upozornit na nejaky problem (samozrejme pokial nie je fatalny).

Alebo spytam sa inac: na co mi je RAID, ktory v pripade zlyhania disku prestane "fungovat"? To tam potom mozem mat kludne jeden disk a v pripade problemu ho vymenim a data obnovim zo zalohy. Vypadok budem mat tak ci tak, takze z tohto pohladu mi to je jedno.

[kralyk z abclinuxu]

Alebo spytam sa inac: na co mi je RAID, ktory v pripade zlyhania disku prestane "fungovat"? To tam potom mozem mat kludne jeden disk a v pripade problemu ho vymenim a data obnovim zo zalohy. Vypadok budem mat tak ci tak, takze z tohto pohladu mi to je jedno.

+1, to mě přesně taky napadlo. Nejsem admin, ale měl jsem za to, že celá pointa RAIDu (resp. tohohle druhu RAIDu) je, aby to bezproblémové fungovalo, i když shoří nějaká podmnožina disků.

[j]

Krystovanoha po 12039781 ... ten RAID normalne FUNGUJE, dokud to ADMIN NEVYPNE!!! Kdyz ho ten ADMIN VYPNE, tak se proste narozdil od shitraidu snazi admina DONUTIT aby ten raid OPRAVIL.

Ucelem raidu rozhodne NENI a NIKDY NEBYLO aby startoval kdyz je fail. Ucelem RAIDu je, ze kdyz ten disk chcipne

!!!!!!!!!!!!!!!!! za chodu !!!!!!!!!!!!!!!!!!!

, tak bezi dal. A da se pochopitelne za chodu opravit.

A to co se tu na 150ti strankach resi, je vyhrane a pouze to, ze imbecilni dementni admini nejsou schopny vymenit disk. Nic vic. A navic tu taci idioti jeste argumentujou tim, ze na failnutym poli budou delat akce, ktery jsou principielne rizikovy i na HW plne funkcnim ... lol.

Pricemz hromada HW radicu umi presne totez, a nektery to tak maji i bydefault, ze pokud je pole pri startu fail, tak ho proste nepripoji. U kritickych aplikaci je pak presne tohle chovani pozadovany.

Je to exaktne stejny, jako kdyz se nekdo bude rozcilovat, ze mu nenastartuje server s vadnou ramkou ... lol. Proc jako asi tak myslis, ze server startuje klidne 30 minut, nez vubec zahaji start OS ... zeby proto, ze testuje funkcnost vsech komponent toho HW?

---

Dete s tim guuglem dopice!

[kralyk z abclinuxu]

Tzn. když chcípne disk za chodu, tak to má nadále fungovat víceméně neomezeně dlouho včetně plné operability, možnosti vyměňovat disk atd. ... ale jakmile to v té chvíli rebootuješ, tak už to nesmí naskočit? Wtf?

[%]

Alebo spytam sa inac: na co mi je RAID, ktory v pripade zlyhania disku prestane "fungovat"?

Btrfs raid nepřestane v případě selhání disku fungovat. Funguje dál, dokud to jde, stejně jako jiné raidy. Akorát v takovém stavu při rebootu nenaběhne a řve, že pole není kompletní. Ale tomu se dá odpomoci přidáním jednoho parametru pro kernel.

A pokud tedy admin jó chce, může si ten parametr zadat defaultně, takže ono se to pokusí nabootovat pokaždé, i když pole kompletní nebude, stejně jako mdadm. Je to jen na adminovi...

[Heron]

A do systemd.timer dát check, který bude případně volat btrfs device delete missing. Potom v případě vypadávání disků se bude jen zmenšovat volné místo na tom fs. A máme z toho ten "enterprise" storage, který se chová vlastně dost podobně. Příslušný admin si to může vyšperkovat ještě tak, že tam dá automatické přidávání device z určitých portů nebo backplane. Takže potom může za běhu vytahovat a zandávat disky a jen se bude měnit dostupné místo na fs.

(Tve to by mě zajímalo, jestli by to fungovalo. Nemáte někdo volnou backplane a hromadu disků na otestování?)

[cezz]

A bude to fungovat uplne paradne az do okamihu kedy ti nejaky disk vypadne a neskor sa znova objavi napriklad preto ze reboot resetol zaseknuty controller. To si mal dat ballance, ale nemal si sa to ako dozvediet, kedze spoliehas na to ze ti to pri boote vyhodi error keby bol problem.

[Josef Kufner]

Akorát v takovém stavu při rebootu nenaběhne

= nefunguje.

[%]

A pokud tedy admin jó chce, může si ten parametr zadat defaultně, takže ono se to pokusí nabootovat pokaždé, i když pole kompletní nebude, stejně jako mdadm. Je to jen na adminovi...

Jakým parametrem při bootu začne mdadm kontrolovat checksumy čtených dat?

[cezz]

mdadm checksum nerobi, ale to asi vies. (mozno uz nieco take dorobili, ale pochybujem)

Ale ked chces porovnavat, pozri na ZFS, ktore nabootuje by default aj degradovany pool. A aj varuje ked pri citani muselo opravit zaznam na disku kde nesedel checksum.

[j]

Kdyz ti chcipne disk, a chces aby to zustalo v provozu, tak jdes, a ten disk vymenis, ze? Rozhodne nejdes delat nejakou udrzbu a pole restartovat ze? Myslis si ze pole za dlouhy penize se chovaji vyrazne jinak? Tak bez to pole trebas aktualizovat v okamziku, kdy tam mas neco v degradovanym rezimu. To pole te posle doprdele.

Tady popisovany a vychvalovany chovani se tyce tak maximalne tupych radicu v obycejnych serverech. A 30 let stary SW implementace tehoz.

---

Dete s tim guuglem dopice!

[cezz]

Disky maju pomerne velku sancu zlyhat pri restarte kedy sa rozbiehaju. (v pripade mechanickych problemov) Ak mi OS po restarte nebootuje lebo odisiel jeden z diskov v mirrore, povazujem to za dost velky problem.

A ak je server niekde v serverovni bez vzdialenej konzoly, moze to nakoniec skoncit vyletom do datacentra namiesto toho aby normalne nabehol a nechal monitoring aby ma varoval ze treba vymenit disk. (Co je casto vec ktora sa da bez problemov naplanovat aj ako servisny zasah on-site podpory narozdiel od troubleshootingu nebootujuceho systemu)

Osobne som nezazil radic alebo diskove pole ktore by nenastartovalo v degradovanom rezime. (bavime sa o situacii kedy nedoslo k strate dat, ide len o znizenu redundanciu)

[trekker.dk]

Ten FS neselže. Jen se v případě výpadku disku chová jinak, než některé jiné systémy.

Chovat se jinak jistě může, ale zásadní otázka je, jestli je dobrý důvod, aby se tak choval. Je nějaký dobrý důvod, proč by filesystém/úložný systém neměl automaticky doplnit chybějící kopie?

[Aleš Kapica]

Pokud vím tak je doplní, pokud má kam, proto taky všem doporučuji používat Btrfs v raid1 se třemi disky a ne se dvěma a držet zaplnění disku jen na takové úrovni aby si v případě problému jednoho z těch disků vystačil ten FS se zbylýma dvěma. A pokud dochází místo, raději zavčas obměnit disky za větší.

Tam kde to nejde doporučuji kontrolovat stav zařízení, jestli se neobjevuje v čítači nějaká chyba a v pravidelných intervalech spouštět scrub. Ten se, pokud vím, o automatické vytvoření kopie postará a ještě o tom podá zprávu. Rozhodně mi to přijde lepší řešení, než automatické nahrazování celého blokového zařízení.

[trekker.dk]

Pro ostatní: kapicabot odkazovaný článek nečetl nebo nedokázal rozparsovat a informace, které zde prezentuje, jsou s článkem v přímém rozporu

[Radovan]

Jdi s tim chronickým hejtováním kapusty někam, neni to vtipný.

[Nikola Ciprich]

Se selháním disku za běhu jsem se ještě nesetkal. Většinou to dostatečně brzo hlásí smart. Tj u btrfs jsem tento problém nikdy nemusel řešit, zato mi pomohl vyřešit spoustu jiných situací. A ano, smart není všespásný, takže když budu muset jednou za x let řešit degraded btrfs, tak se z toho nezblázním.

ke zbytku se nevyjadřuju, ale toto je za mě naprostý nesmysl co tady šíříte. Kolik těch serverů máte? my jsme jich za posledních cca 20 let nainstalovali (a spravujeme) několik tisíc. A to co tvrdíte prostě není pravda. Disky UMÍRAJÍ bez varování (to mluvím jak o rotačních, tak SSD), nezávisle na značce. Jsou na to dokonce i velice dobře zpracované analýzy od společností, které těch serverů mají desetitisíce a pečlivě si to evidují. A i z těch je vidět, že SMART může varovat předem, ale ve spoustě případů nevaruje.

[Heron]

Dneska už několik tisíc. Ano, to že smart nevaruje vždy je jasné. Ale je také jasné, že server může selhat z jiných příčin. Proto nemá smysl řešit tak moc každou jednotlivost, ale od určité chvíle se na to podívat s odstupem a říct si "co se stane, když celý tento server odejde?". V závislosti na odpovědi na tuto otázku to potom lze řešit dál jinými prostředky. Proto od určité velikosti nemá moc smysl řešit každý jednotlivý fs, protože v běžném provozu se s vyšší pravděpodobností vyskytují i jiné události.

Takže trvám na své předchozí odpovědi. Pokud jednou za x let odejde disk bez varování, tak se z toho nezblázním.

[trekker.dk]

Pokud jednou za x let odejde disk bez varování, tak se z toho nezblázním.

To je dobře, nicméně to furt nevyvrací, že tento způsob chování btrfs je zhovadilý, ani proč je takhle zhovadilý.

[Heron]

Nevyvrací, ani neměl. Ale jestli někdo probádá historii a zjistí, proč to tak je, může to sem postnout.

[Aleš Kapica]

Že ti vůbec stálo za to na tyhle výkřiky reagovat. Článek onoho odborníka alá Vlasta Waic je akorát vodou na mlýn pitomců, co Btrfs neumí používat, poněvadž nepochopili jak se s ním pracuje. Ať si používají co chtějí. Měl jsem v práci jinší nevěřící Tomáše, co dnes na Btrfs nedají dopustit.

[kralyk z abclinuxu]

btrfs poskytuje skvělé služby pro ty, kteří je mají kde využít a samozřejmě, jako všechno, má svoje quirky. Stejně jako každý jiný fs.

To je trochu relativizace. Takové quirky jako btrfs IMO opravdu každý jiný fs nemá. Když jsem naposledy btrfs zkoušel, dostával jsem celkem běžně panicy. Pravda, bylo to roky zpátky, ale po tom, co bylo odstraněno to varování o experimentálnosti. Tohle je něco, co se ostatním/seriózním FS nestává.

Což jako samo o sobě není nutně špatně, chápu, že některý věci jsou nestabilní a trvá dlouho je odladit, ale chtělo by to v tom případě jasně označit nějakou základní podmnožinu funkcí jako stabilní a tu udržovat maximálně robustní...

[Heron]

To je trochu relativizace.

Ne není. Pokud mám nástroj, který mi nabízí funkce, které nikdo jiný nenabízí, tak to nemám s čím srovnat (relace). btrfs je v tomto unikátní a žádný jiný fs mi v tomto nenabízí takovou flexibilitu s prací jak se zařízeními, tak s subvolume. Kdy můžu přidávat a ubírat zařízení, jak potřebuju a totéž můžu udělat se subvolumy. (Na zfs neustále narážím na to, že dělat clone se v budoucnu hodně nevyplatí, takže raději dělám plné kopie pomocí send a receive.)

A když tohle všechno vím, včetně těch nepříjemných vlastností, tak je můžu buď obejít (třeba tím, že všechny device budou redundantní na jiné vrstvě a btrfs tak nikdy neuvidí selhání disku) nebo se na ně prostě připravím. Záloha je stejně nutnost, takže je lepší se připravit na to, že ji budu potřebovat (zfs mi teď hlásí, že mám celý pool obnovit ze zálohy.)

Prostě, žádný fs není dokonalý.

Když jsem naposledy btrfs zkoušel, dostával jsem celkem běžně panicy.

To je trochu škoda, že to není i s odkazy na jednotlivé případy (neříkám bugreporty). Tohle beru už je jako takové plácnutí v diskusi.

ale chtělo by to v tom případě jasně označit nějakou základní podmnožinu funkcí jako stabilní a tu udržovat maximálně robustní

Možná jsem se jen omylem trefil, ale od roku 2010 používám raid1, masivně subvolumy se vším (snap, send, receive), multidevice management (pravidelná výměna disků), balance (změna z původního linear na raid1, za běhu). Víc tak nějak ani nechci. Takže toto je ona stabilní množina

[kralyk z abclinuxu]

To je trochu škoda, že to není i s odkazy na jednotlivé případy (neříkám bugreporty). Tohle beru už je jako takové plácnutí v diskusi.

Jo, to je fér, v této chvíli už to je spíš JPP a ideálně bych si to měl vyzkoušet znova... (Ale zatim moc není motivace.)

[honič]

Přinutilo mě se podívat na čem mám uložené porno.

[EXT2]

Nebyl RAID vyvinut kvuli HDD (pomalosti (R0) a dobovym FS ktere nemely schopnosti overeni integrity dat proto R1+) a pro SSD, Nvme uz nema R0 v podstate smysl (sice bude stale rychlejsi ale i bez neho nebude znat pomalost jako driv u HDD) a R1+ ma alternativu v podobe FS se scopnosti overeni integrity dat v soucinnosti nejake synchronizace v domaci siti?

[Peter Golis]

Ono to nie je len o overení integrity, ale je to aj o zachovaní integrity pri výpadku časti údajov. A aj o automatickom zásahu ktorý zabezpečuje rezervný (sparse) disk, a vyšperkovaná na okolo.

[Heron]

Raid byl vyvinut (několikrát) z mnoha důvodů. Bohužel zrovna zajištění integrity dat neumí. Neukládá si nikam checksum a pokud jsou v mirroru pouze dva disky a data se vzájemně liší, nelze nijak poznat, která jsou ta správná.* Už jsem se potkal s případy, kdy se to synchronizovalo ze špatného disku a fs byl v háji. To by ty disky v mirroru musely být alespoň tři a doufat, že dvě kopie budou souhlasit. Toto právě řeší fs s checksumem dat (zfs, btrfs), a tyto dovedou určit (a to i na jednom disku) zda jsou data v pořádku a při větší redundanci i to, která data jsou ta správná (s pomocí dalších metadat).

*) V takovém případě je lepší raid odstavit, aby se nečetla vadná data a nešířila se tak dál.

[PetebLazar]

To, že jsou v třičlenném RAID1 dvoje data stejná nemusí nutně znamenat, že jsou ona ta správná. Ta správná (konzistetní s ostatními daty) mohou být klidně ta na zbývajícím členu (například když se na zbylé dva členy kvůli pádu již nestačila propsat).

[Heron]

Ano, nemusí. Ono těch případů rozpadu na více validních částí může být víc.

[F.F.]

+1 been there done that, intel deska s HW mirror raidem, jeden disk zacal delat psi kusy a ten druhy poslusne ty chyby zduplikoval... Nastesti to byl jen stage server s denni zalohou v NAS.

[luky]

Raid byl vyvinut (několikrát) z mnoha důvodů. Bohužel zrovna zajištění integrity dat neumí.

RAID 2 umoznuje urcit, ktera data jsou poskozena a opravit je - napr. pri pouziti Hamming(7, 4), je mozne jednu chybu opravit a 2 detekovat. Je pravda, ze se uz nepouziva (protoze je levnejsi si koupit disky, ktere detekuji chyby samy a pouzit jinej raid), ale tvrdit, ze to neexistuje, je lez.

[odbornik]

Proste si kup velkej disk a kdyz ti i to bude malo tak USB lol a nemusis resit RAID

[Miriam]

Nejlepší file system je Reiser4, ale CIA v něm neměla backdoor, tak zavraždila Hansovi manželku a shodila to na něj. Nejvíc líto je mi jejich dětí, ten jeho syn byl v Rusku brutálně zpracovanej

[Rolf]

A v kterem FS ma CIA backdoor? A ses si jista ze ten o jakem mluvis je vyvinut vubec v USA?

[Rolf]

Treba takovy ZFS je dnes Oracle tj Mnichovska spolecnost na oko zalozena i v USA, takze ten backdoor by tam dala spis nemecka sluzba. A ted jeste vedet jestli i te Sun Microsystems byla spolecnost kompletne z USA?

[Max]

MIriam, nepřeháníš to trochu s hulením?

[o|o]

hulenim ceho?

[P.Fiala]

Díky za sdílení článku, už mám dost místních »expertů«, co spravují pár počítačů v družině a mají čas trávit den opravováním zborceného fs. Někteří z nás potřebují řešení, na které se dá spolehnout, a zde se problémy nesmí lehkovážně zametat pod koberec.

[Miriam]

Bez těch osobních útoků a strawmenů by to nešlo, ty mrdko?

[vencour]

To je zase příspěvek ...
Já taky nikomu reisera nebo něco jiného nevnucuju ...

[alkoholik]

To se chlubis, ze nemas poradne zalohy nebo co?

[hmm...mmmlask]

to vis lidi jako heron se dostaly [sic] k pocitacum pres koureni curaku tak si tady honi ego nad uspesnym autoream a sysadminem.

[hmm]

Mluvi po slovensku, ty troli reinkarnace Trochu naivni Kapico aka AmigoPowerD

[Aleš Kapica]

Vem si prášek.

[Jana Dziková]

Aleši, vem taky rozum do hrsti, nekrm troly!

[Angela]

To se uz nenosi, my dnes troly integrujem v ramci diverzity.

[Angela]

Mykhul???

[Miriam]

ábíčko na mě a na dvojté wéčko dostalo grant, já se učím programovat v pythonu a dvojté wéčko dostal počítač, se kterým už se tři roky neúspěšně pokouší připojit k síti

[PetebLazar]

Divím se, že ještě někdo článek neoznačil za ZFS spiknutí. Autor článku je co-host podcastu 2.5 Admins s Allanem Judem a Joe Ressingtonem.

[jamest]

Btrfs je šílený paskvil. Implementace ZFS taky. Zlatý Solaris/Illumos nebo FreeBSD se ZFS v jádru/přímo v systému. A to nemluvím o šílené GPLv2 a GPLv3. Kolegům linuxákům to fakt nezávidím.

[j]

Vazne k popukani ... specielne kdyz nejakej tupec (ten v co napsal ten clanek, ale nejen) kritizuje neco, co dodavaji i ti nejvetsi dodavatele HW, a vychvaluje to, co uz se prakticky vubec v nicem nepouziva.

Mluvim v tomhle pripade prave o raidu, protoze dneska se klasika na blokovy urovni vubec nepouziva, jednoduse proto, ze to je strasne neefektivni a neflexibilni. Takova srandicka jako ze si nekdo vzpomene, ze je potreba pole prekonfigurovat (za chodu pochopitelne), je s klasikou prakticky zcela nerealizovatelna, zatimco s btrfs je to trivialni ukon.

A vubec nekrasnejsi sou zvanilove ktery vytykaji btrfs to, ze se PO RESTARTU nepripoji SAMO pole v degradovanym rezimu. Kolik ja jen videl HW poli, ktery samy v tom degradovanym rezimu prede vpohode dal fungovaly, az do okaziku kdy pochcipalo tolik disku, ze to uz dal neslo. Nehlede na to, ze jedinim parametram ve fstabu se da zaridit presne stejny chovani.

---

Dete s tim guuglem dopice!

[GeorgeWH]

Kolik ja jen videl HW poli, ktery samy v tom degradovanym rezimu prede vpohode dal fungovaly, az do okaziku kdy pochcipalo tolik disku, ze to uz dal neslo.

Aha, cize to, ze nieco zlyha, je problem samotnej technologie a nie toho, kto si to mal sledovat? To dava logiku...

[j]

Je to PRESNE stejny, jako nase uzasne "zabezpecene" trate. Kdyz neco selze, ma system zabezpeceni zajistit, aby to selhalo bezpecne. A tvurci btrfs se rozhodli, ze proste restart === zasah admina === neni naprosto zadnej duvod, aby pole ktery selhalo bezelo dal.

Mistni zvanilove tu pak blabolej o zpusobenym vypadku, ale ten zpusobil admin, ne to pole, pole bezi, dokud ho nerestartuje. A kdyby admin nebyl tupec, tak nejdriv vymeni ten vadnej disk.

Md se pak chova presne stejne jako tupy radice tupych poli, a degradovanej, a tudiz nefunkcni raid i po takovym zasahu pekne v klidu a vpohode pripoji, jako by se nechumelilo. Jo, mozna to nableje neco do dmesg, ale kolik promile soudruhu adminu se tam podiva aspon jednou za rok?

Ve finale, jak i tady zaznelo, kdyz od neceho chci aby to melo nejaky garantovany provozni parametry, tak to nebude ani md ani btrfs raid, ale neco (vcetne supportu) si koupim. Celkem by me totiz zajimalo, jak budes ve 3 hodiny radno v nedeli shanet nahradni disk, zatimco ten support mi ten disk klidne i ve 3 rano priveze. Uz vubec nemluve o tom, ze v takovym poli bude i nekolik "spare"* disku.

*Uvozovky jsou tam zcela umyslne, protoze opet, spare je disk z klasickyho pole, kterej nic nedela a nenese zadny data, coz se opet uz nepouziva, dela se to tak, ze ty disky normalne generujou IOps a jsou na nich data, ale celkova kapacita pole je takova, ze muze i nekolik disku selhat, aniz by se pole dostalo do degradovanyho rezimu na vic nez par minut.

---

Dete s tim guuglem dopice!

[Heron]

ale kolik promile soudruhu adminu se tam podiva aspon jednou za rok

Už jsme mimo téma, ale tohle mi připomnělo jeden velmi pečlivě monitorovaný server od člověka, který má nutkání nastavit úplně všechno (a to si nedělám prdel, snad každý soubor v /etc byl upraven). Bylo tam asi 200 checků na kde co všechno. Jenže jeden chyběl.

Tento člověk se potom rozhodl, že je potřeba toho nastavit ještě víc, takže začal dělat i speciální (lvm) oddíly pro každou službu a linkovat(!) tento mount do /var/neco.

Po nějakém update nebo tak něco se tento link smazal a data se ukládala přímo do /var/neco. Jenže var se nemonitoroval, protože je přece vždycky prázdný (jsou tam jen linky...).

Příběh s mdadm. Někdo se rozhodl, že jeden disk je málo, tak tam dal raid (což je pořád lepší, než single disk). A neupravil monitoring. mdadm svoji funkci plnil, několik let to běželo pouze z jednoho disku, druhý byl vadný. Jednoho dne se rozhodl odejít i druhý disk.

Příběh s bootem. Někdo vyměnil disk v mdadm (který se nějak zázrakem monitoroval) za jiný, jenže místo gpt tam dal mbr. Stroj po výpadku prvního disku nenabootoval.

Fakt bych chtěl žít ve světě, kde je jediným problémem na serverech to, že btrfs občas potřebuje mount parametr.

[plostenka]

RAID je od toho, aby pri vypadku n disku pole bezelo dal jako by se nechumelilo. Nahradni se vezme automaticky ze spare grupy a admin casem jen sahne do krabice a vymeni vadny kus za novy (ten novy automaticky bude spare pro priste).

Kdyz admin restartuje server, treba jen kvuli upgrade kernelu, tj bez souvislosti s polem, tak to posledni co chce resit je debilni implementace btrfs.

[GeorgeWH]

+1

[hm]

-1

[%]

A tuhle nedebilní implementaci mdadm zvládá? Jako že se na to nemusí sáhnout jiným způsobem, než že se vytáhne ten vadný disk a místo něj se dá disk nový?

A nebo snad s mdadm taky někdo musí udělat ještě čárymáryfuk, disku připoj se do pole?

[Tom K]

Mdadm zvládá automaticky použít spare, pokud mu disk odejde.
Odebrat vadný disk a přidat nový spare je třeba ručně, protože mdadm narozdíl od HW raidu nemůže tušit, že nově vložený disk bude nový spare.
V době, kdy vznikalo mdadm se IDE disky nedaly běžně odebírat a přidávat hotswap. Takže podobná logika nebyla potřeba.

[%]

Takže to skoro vypadá, že je to implementováno debilně, jako se zmiňuje předřečník o btrfs, že ano?

[j]

Pokud ty adminujes cokoli jinyho nez trikolku, tak si zaslouzis viset ze kule v pruvanu. Naprosto neexistuje ze admin jede restartovat cokoli vadnyho a naprosto neexistuje ze bude menit kernel na poli kde je chciplej disk. Takovyho admina bych na miste ubil a minimalne dostane k uhrade veskery skody ktery svoji naprostou neschopnosti zpusobil.

---

Dete s tim guuglem dopice!

[plostenka]

Admin pres SSH upgraduje kernel a restartuje. Naprosto ho nezajima, ze si mezitim RAID vymenil chciply HDD za spare, na funkci pole to nema vliv, jen zapis bude trochu pomalejsi kvuli rebuildu. O nahradach skody si povime, az pri bootu system hangne kvuli nepripojenemu btrfs.

[%]

A to jako pořád mluvíš o tom mdadm raidu, že ano?

[plostenka]

Pochopitelne. HW RAIDy s neznamymi bugy, quirky a "featurami" mi nesmi do serverovny a ze softwarovych je mdraid jedine rozumne reseni.

Ano, mdadm umi automaticky pouzit spare disk, umi na pole zapisovat i pri rebuildu, umi rebuild pozastavit/obnovit okolo rebootu.

Nevidim problem.

[%]

Mdadm umí použít automaticky spare. Ale neumí automaticky použít nový disk, který tam vrazíš místo toho vadného. Někdo musí tomu poli říct, aby to udělalo. Takže v tomhle to není o nic chytřejší, než btrfs, ačkoli jsi něco takového naznačoval, když jsi nazval implementaci btrfs debilní.

A pokud se staráš o nějaké konkrétní diskové pole, tak bys asi měl vědět, co máš udělat, aby to pole nový disk schrouplo. btrfs, mdadm nebo cokoliv jiného.

Kromě toho silně pochybuji, že by tvoje bankovní a korporátní servery, 100 km vzdálené, neměly nějakou tu vzdálenou konzoli, na které by se dalo zařídit, aby btrfs nabootovalo v degradovaném režimu, pokud by ho tedy ta banka či korporát používaly.

Nevidím problém.

[j]

Ale ony ty servery adminuje uplne stejne jako fuckbook ty svoje, vis? https://www.abclinuxu.cz/zpravicky/facebook-offline-4.-10.-od-17.00-utc

A presne podle toho to pak vypada ... ;D, potrebujes dynamit, aby ses k tomu serveru vubec dostal a moh ho restartovat ...

---

Dete s tim guuglem dopice!

[j]

Doufam ze si tvuj zpusob prace precte tvuj chleboderace, jiste bude nadsen z toho, az o ty data konecne prijde. Sem zvedav jak mu pak budes vysvetlovat, ze admina prece nezajima nejaky blby pole v degradovanym rezimu, protoze to ma prece fungovat a predevsim drzet hubu.

Opravdu me ale dojima, kolik dementu ktery nezvladnou do fstabu pridat jedinej parametr, sem leze.

---

Dete s tim guuglem dopice1

[alkoholik]

Mas naplanovany downtime - upgrade OS a databaze - jedine hodinove okno za rok.
Sedis nachystany v kanclu a v serverovne 100km daleko zrovna chcipne disk.
Upgrade odlozit nemuzes - stovky az tisice lidi dostali notifikace - a disk vymenit taky ne.
J te jde ubit..

[Heron]

Mno. Pokud je nějaký stroj tak důležitý, že je možné jej odstavit pouze jednou za rok, má být redundantní.

Pokud je to 100km daleko a z nějakého záhadného důvodu nelze zavolat obsluze pro výměnu disku ani se tam nelze připojit na KVM / management consoli (ilo, ipmi), tak je to celé nějak špatně navržené.

Nemá smysl dávat absurdní příklady, kdy všechno selhalo jenom na fs. Při tom update os a db se mohou stát jiné věci. Zvláště, když se to dělá ve spěchu jen jednou za rok.

[alkoholik]

Treba Upgrade Oracle 12->19 bezvypadkove neudelas. A pri downtimu se holt dela i OS.
Na KVM se samozrejme pripojit da, ale posledni co chces, je ve stresu lovit parametry pro zkurveny fs.
Absurdnich situaci jsem uz zazil dost na to, abych vedel, ze se proste vyskutuji.

[Heron]

Nechápu, proč by se měl update dělat ve stresu. Update je standardní technická záležitost, která se má dělat pravidelně. Pokud je to ve stresu, tak je evidentně někde problém.

Jako už jen požadavek na délku odstávky... Nejhorší věta v IT je: "Uděláte to bez výpadku!" To, co by se v klidu zvládlo do 20 minut někdy v pracovní době přes den i se dvěma rebooty, tak se musí dělat "bez výpadku" ve tři ráno (protože těch klientů je tam strašně moc) a potom to do rána dávat dohromady.

Tohle prostě nejsou technické problémy ale jen a pouze problémy návrhu a řízení.

[alkoholik]

Ocividne nedelas ve finacnim sektoru. Tim nemyslim srandabanky, u kterych kazdy treti vikend rano nemuzes zaplatit kartou. A to zatim nefrci instant SEPA.
Stress vznikne, kdyz das reboot a cekas na konzoli a cekas a cekas, protoze nejaky debil si rekl, ze degradovane pole pro tebe pri bootu proste neni dost dobre.
Osobne bych se pristupem - neumim to navrhnout bez vypadku - moc nechlubil.

[Heron]

Pro banky, kde je problémem i v jaké vzdálenosti od admina je server, skutečně nedělám.

Já to umím navrhnout bez výpadku. Důležité služby jsou replikované ve více kopiích a odstrávka jednoho serveru klidně může probíhat týden.

[alkoholik]

Problem to skutecne neni, protoze nedodelek brtfs nepouzivame.
Ano, dulezite sluzby jsou replikovane, ale kdyz ti Oracle support napise, at si naplanujes odstavku, tak jsi nahrany.

[Heron]

Tak alespoň je to drahý, no.

[alkoholik]

Drahy a priserny.
Bohuzel jde o desitky let stary vendor lock-in a nikdo nevrazi prachy do prepisu do neceho pricetnejsiho.

[j]

Jestli ty delas v bance, a provozujes bankovni system na btrfs poli, tak se divim, ze te jeste tvy chlebodarci nenechali namlejt do konzerv. Tim ze provozujes pole v degradovanym rezimu a jeste na tom delas aktualizace a restarty se vazne mas co chlubit ...

Mam zakose kterej jede 24/7 a sem tam se planujou odstavky. Ne proto, ze ty technicky neslo danou vec resit za chodu, ale proto, ze to tak je bezpecny. Je tam prostor vse otestovat a pripadne vratit backup, sem zvedav, jak budes za chodu vracet backup ... a jak budes vysvetlovat, ze ty prachy z tech uctu sice zmizely, ale na cilovych se neobevily, protoze proste sme neco delali za chodu, a v puce se to posralo ... a na tom degradovanym poli nam chcipnul druhej disk, protoze sme zrovna reindexovali databazi a tudiz ty disky dostaly pekne naprdel.

Pokud chci provozovat bezvypadkovy uloziste, tak jich provozuju vic. A data se na nich replikujou.

---

Dete s tim guuglem dopice!

[alkoholik]

Praveze na takove sracce jako je btrfs bych si to nikdy nedovolil.
Vsechny postupy jsou samozrejme pred upgradem otestovane na stejnem SW/HW a jak dlouho trva recovery, kdyby se pres vsechno testovani neco podelalo, vi i management.
Musis si vybrat si, bud jedes skutecne 24/7 a nebo si na to s odstavkami jenom hrajes. To jsou ty devitky v SLA, vime?

[plostenka]

Obcas je potreba prejit nikoli z verze na verzi, ale z jednoho datoveho formatu do jineho. Zrovna banky a jine stare korporaty se spoustou transakci/s narazi(ly) nejdriv na 4GiB hranici velikosti DB, pak 4G radku v DB, nebo 32k indexu/DB... a tak. V 80s a 90s bylo to omezeni nekonecne daleko.

A tohle bez vypadku udela jenom kouzelnik bez ohledu na to na kolika geograficky oddelenych nodech DB bezi, protoze se to musi udelat vsude najednou. Akce je naplanovana na nekolik mesicu dopredu, vsichni dodavatele toolchainu okolo te DB maji pohotovost, on-call je presmerovany z Indie primo k clovekovi s >10 let praxi a kazdou minutou nad ramec SLA litaji 100k$. Been there, done that.

Ale mas pravdu, muzou se stat i jine veci kdyz se to dela jednou za... no ten co to delal posledne uz je v duchodu.

[Heron]

To ty DB v bankách neumí replikace (alespoň sousední verze) a výměna on disk formátu musí proběhnout všude ve stejný čas jo? Je přece naprosto normální, že software buď umí pracovat s několika formáty dat (minulý, aktuální) a pokud ne, tak umí běžet co node, to různá verze, aby se mohlo hladce přejít na nový formát.

Jako nevím no, tohle je pro mě známka "enterprise" řešení. Základní věci to neumí, ale postaví se k tomu armáda lidí, měsíce plánování, aby se to potom udělalo všude současně.

[plostenka]

Samozrejme ze z N-1 na N a na N+1 zmigrujes multi-node online, kdyz chces. Ale...

Zjevne nemas zkusenost s extremne konzervativnim IT prostredim. Co funguje, na co je audit a papir o konformite, na to se nesaha a zakaznici si plati extended support a pak jeste obchodaci vyjednavaji post-EOL support jen aby nemuseli zmigrovat na novou verzi - nemaji moc zajem o nove features (teda pokud prave nenarazili na limit viz vyse), ale maji zajem na to nesahat. Jenze casem je situace neudrzitelna a migruje se najednou pres nekolik releasu na ten druhy nejaktualnejsi (z verze "pravek" na N-1), protoze je predpoklad ze tam uz nejsou neobjevene bugy. Tim padem se ale stane, ze se preskoci okno deprecated-dropped a sam vidis problem.

Nekteri aktualizuji prubezne (prave aby mohli migrovat online a mit levnejsi support), ale zdaleka ne vsichni.

[j]

Vedet nemusis, to je jen nepatrna ukazka toho, kdo to adminuje a kdo to navrhuje.

Onehda mi pres rameno jeden takovej nacumoval, a strasne se divil, ze si normalne za provozu a pres den dovolim jakoze aktualizovat a restartovat cely servery ... To sem si totiz podle nej moc dovoloval, kdyz sem si vyklidil hosta (pro ty tupejsi, virtualy z nej sem presunul na jiny hosty - za chodu == zazrak), a na nem sem si patchnul jak vsemozny firmware, tak pochopitelne i ten vmware ... a takhle sem behem dne protocil 1/2 serveru. Protoze tu druhou si dycinky nechavam tak za dalsich 14 dnu, to kdyby se zjistilo, ze novy verze maji nejaky zasadni pruser.

Mno zdejsi soudruzi by tohle provadeli nad polem v degradovanym rezimu, takze by jim to asi tak do 5ti minut chciplo cely, a pak by se strasne rozcilovali, ze za to muzou tvurci btrfs.

Vis jak delam "vypadkovou" vymenu verze databazi? Cece ... to je ti akce ... na asi tak 2 minuty. To si totiz predem pripravim novej stroj s novou verzi SQLka. Nastavim to a otestuju, pripravim si scriptik, a pak behem tech cca 2 minut provedu kick na vsechny sessions, detach a attach na novou verzi a voiala.

---

Dete s tim guuglem dopice!

[alkoholik]

Takze bez testu upgradujes produkcni servery a cekas, jestli se nahodou nevyserou?
To uz ani neni vtipne.

[j]

Zjevne narozdil od negramotnych dementu jako ses prave ty, nikolivek.

---

Dete s tim guuglem dopice!

[alkoholik]

Zase meles hovna:

Protoze tu druhou si dycinky nechavam tak za dalsich 14 dnu, to kdyby se zjistilo, ze novy verze maji nejaky zasadni pruser.

Tohle nema poradny admin zapotrebi, protoze to ma otestovane jinde nez na produkci.

[Heron]

Tak přepnutí vmware do maintenance je otázka jednoho kliknutí. Potom se stačí vzbudit, až je hotový odstěhování VMek (tuto funkci citlivého probuzení admina nemají ještě zcela vychytanou) a provést něco s tím HW. Takto nám běžela vmka s uptimem delším než bylo průměrné stáří HW. (Bylo to cosi na RHEL4, vykopávka. Uptime od nastěhování do nové serverovny.)

Ale jako zrovna tohle není problém, klikat v vmware se naučí kde kdo.*

Vis jak delam "vypadkovou" vymenu verze databazi?

Tve nekecej, tohle jde jo?

Trochu mi to připomnělo, jak jsem kdysi komusi ukazoval, že rsync lze spustit i vícekrát, takže finální přehození služby ze stroje A na stroj B lze udělat během pár sekund: stop - finální rsync - start na novém. A to i s přehozením IP.

[alkoholik]

Neaplikovanim kernel security patchu bych se moc nechlubil.

Vis jak delam "vypadkovou" vymenu verze databazi?

Tve nekecej, tohle jde jo?

To samozrejme jde, jenze databazovy admin zna rozdil mezi databazovym enginem a samotnou databazi.
Kde je upgrade data dictionary? Kde je upgrade JRE? To je totiz porad stara verze databaze.

[Heron]

Já se tím nechlubím. Já jsem několikrát navrhoval ten stroj vypnout a smazat.

[kralyk z abclinuxu]

Pokud je nějaký stroj tak důležitý, že je možné jej odstavit pouze jednou za rok, má být redundantní.

Redundance může být v některých případech poměrně náročná nebo nemožná. Viz talk. Redundance obchodního backendu vyžaduje konsensus algoritmy velmi náročné na implementaci. Redundance/load-balancing vstupní gateway může být nežádoucí, protože lidi by toho zneužívali k získání nefér výhod... Otázka ale je, jak tohle souvisí s diskovýma polema, protože tyhle věci by měly být virtualizovaný a když se stane cokoli na nižší vrstvě (od OS níže), tak odmigruješ služuby jinam a řešíš OS/hardware.

Počítám, že ten reálný problém v diskusi je ten, že smradlavá Oracle DB je licenčně vázaná na hardware.

[j]

Nikoli soudruhu, ubit ses ty, viz Heron. Ja narozdil od tebe a dalsich tupcu navrhuju infrastrukturu tak, aby selhat mohlo cokoli. Pochopitelne v souladu s tim, jake pripadne skody to selhani muze zpusobit potazmo tim, kolik je ochoten majitel/provozovatel zaplatit za to, aby dana cast infrastruktury neselhala.

Disk v poli zvladne po telefonu vymenit i uklizecka, takze opet narozdil od tebe nikam jezdit nemusim. Navic je v normalnim poli spare, nekdy i vic, takze sme zase u toho, ze ses tupec, protoze pole ktery se prepocita na spare, NENI v degradovanym rezimu. Coz samosebou plati i pro btrfs like fs, kde navic tech "spare" disku je presne tolik, kolik volny kapacity pole vzhledem k poctu disku ma.

Pred jakymkoli kritickym zasahem do infrastruktury se pak kontroluje fukcni HW i SW, a pole bez disku === absolutni NOGO. A je uplne jedno co jak bylo nebo nebylo planovany. To nikoho nezajima, protoze, pro tebe zjevny prekvapeni, vetsina majitelu tech dat o ne prijit, narozdil od tvych ovecek, zjevne nechce.

A co uz vubec nedokazes pochopit, je prosty fakt, ze ten HW prave pri ruznych servisnich zasazich typicky dostava nejvic naprdel, a tudiz hrozi zdaleka nejvyssi riziko, ze neco failne. Takze ti preji uspesny fail disku v degradovanym poli, protoze si prece sel jen vymenit SQLko na jinou verzi ... lol.

---

Dete s tim guuglem dopice!

[kralyk z abclinuxu]

Všichni jsou tupci, každýho bys ubil nebo mu dal přes držku v Uhříněvsi... S tebou bych nechtěl spolupracovat ani na výměně žárovky, i kdybys to dělal sebelépe...

[Heron]

Já zas jo. Mám plné zuby reálného stavu IT v česku, kdy: "se to nějak udělá", "to se vyřeší potom", "nepotřebujeme záložní server", "odstávky se dělají mimo pracovní dobu", "vydíte, vlastně to dobře dopadlo", "ta noční nebyla tak hrozná".

Nejhorší na tom je, že spousta lidí ani neví, že jdou věci dělat jinak a prostě berou jako fakt, že makají ve tři ráno. Nikoho nenapadne to navrhout tak, aby výpadek čehokoliv nezhodil celý systém. Všechno je na to připraveno. Máme více linek do internetu, více zdrojů, switchů, distribuované fs, appky schopné běžet za několika loadbalancery apod. A potom někdo "v bance" má hodinu na update db. A to ještě na Oracle. To i ten blbej postgresql umí běžet za proxy a umí se zreplikovat ze starší verze na novější. SQL klienti si ničeho ani nemusí všichnout, jejich dotaz právě vyřizuje nový server. A to nemluvím o řešeních typu Mongo / Elastic, kde se automaticky počítá, že těch nodů tam bude 15.

[alkoholik]

Tohle vsechno vim a, kde to jde, i mam. U Oracle to proste nejde.
BTW: ani logicka replika u PG neni vsemocna.

[Heron]

Není všemocná. Ale alespoň to mám k disposici. Stejně na to nijak nespoléhám, ty appky nad tím to používají jen jako storage a umí se přepínat. Za ty prachy celkem dobrý.

[alkoholik]

Jestli vam disky muze menit uklizecka, tak byste neprosli prvnim auditem ty sasku.
Uzivatelum a obchodnikum je ve skutecnosti uplne jedno, v jakem stavu mame infrastrukturu. Oni chteji jenom zaplatit. Kdykoliv.

[j]

Jiste vymazance a tvoje pole v degradovanym rezimu auditem jiste projde, ze? Moje uklizecka je zjevne o nekolik radu kvalifikovanejsi osoba nez ses ty a mnoho dalsi zdejsich zvanilu.

Ted uz taky velmi dobre chapu, proc kazdorocne ctu nekolik clanku jak opet nejde zaplatit kartama a opet nejde poslat penize na ucet. A uz se ani nedivim tomu, ze to nekdy trva i par tydnu, kdyz to adminujou podobny bridilove.

---

Dete s tim guuglem dopice!

[alkoholik]

Jasne ze projde, protoze to je normalni provozni zalezitost. Nulova bezpecnost HW rozhodne ne. Nech se od uklizecky proskolit, asi fakt bude lepsi nez nejvetsi mistni zvanil j.
Ja pro zmenu pochopil, kde se berou vsechny ty vykradene databaze.

[ffzzch]

Za mna (nasadenie na domacom nas, cielom je "zaloha" a nie high availability) je znacny rozdiel medzi mdadm raidom a btrfs. Konkretne som pouzival dakedy mdadm v raid10 s n=3. Teda 9 diskov a vsetko trojmo. Ked niektory disk pri citani povedal, ze neprecita, tak mdadm sa na to vysral a nezistil, ze zvysne dva disky vravia daco a nezistoval, co je pravda. Proste chytil nejaky iny, "funkcny" disk a dal odpoved... Toto ale btrfs nerobi. To nie je ako svokra a manzelka (kazda vravi ine a clovek si musi vybrat). Btrfs si pozrie checksumy a vie, kto ma pravdu a vie to opravit.

Za mna nic lepsie na moje pouzitie a potreby nieje. A tiez som rad, ze sa system netvari, ze sa nic nedeje, ked sa snazim nastartovat vypnuty pc do degraded stavu. Pri boote je casto niekto pritomni a vie dany problem riesit (i ked pri rozumnom monitoringu sa odideny disk zo slusnosti riesi kus skor).

[Fredy72]

Ačkoliv jsem zastáncem BTRFS, používám ho, protože má pro mě na domácím NASu nejvíce výhod, tak jsem taky dlouho váhal, zda jít na něm do RAID 6. Jenže ten se mi pokusně podařilo zbořit poměrně brzy. Tak jsem zkoušel RAID6 + RAID1C3 na metadata, to sice byl lepší výsledek, struktura vydržela, ale data taky změněná. Co se mi nepodařilo sestřelit byl RAID1C3 (pokusné odpojování dvou disků za běhu, i chvilkové jako výpadky kabelu, náhodných 1000 bajtů do dvou disků na nízké úrovni atd.). Chce to sice zásah správce, ale data jsou stále totožná. Tady se taky pokoušel rozbíjet a výsledek obdobný khimaros.

[kafe]

No, tak v Enterprise Linuxech nám ho odstranili, na Stratis nejde instalovat, tak... zpět k XFS a LVM :(