Já osobně jsem byl kdysi v minulosti btrfs nadšen a dal mu šanci několikrát, a pokaždé jsem byl dost nepříjemně zklamán. Možná se od té doby (asi 3-5 let) spousta věcí změnila, ale nemám odvahu to zkusit znovu. Přecejen u filesystémů se ztracená důvěra buduje jen hodně těžko.
Domácí server - dva disky v mirroru. Nějakou dobu vše OK, pak jeden z nich zazlobil (nějaké ty read errory), btrfs se odmítnul namountovat, už si nepamatuju přesně jak jsem ho nakonec přesvědčil alespoň na read-only a většinu dat přesypal na externí disk, a následoval reformát na ext4 nad md, kde běží bez chyby dodnes (i přes další 2 odešlé disky).
Performance taky nebyl žádný zázrak (velmi slabě řečeno, v porovnání s ext4), když nad ním běžely 3 virtuály pod Xenem.
Na notebooku (tuším s Ubuntu) bylo vše hezké, až po nějaké době boot pravidelně zůstával několik minut viset při mountu rootového btrfs (i po korektním shutdownu) se svítící LEDkou od disku. Tak tam šel ext4 a byl klid.
ano, podobne skusenosti som mal aj ja. Tiez domaci server, odisiel zdroj a zobral zo sebou jeden zo systemovych SSD diskov (v RAID 1). Druhy mal poskodene data. Najskor siel mount ako read-only, potom som na neho postval nejaky repair a svoje data som uz odvtedy nevidel :-( Bolo to cca 2 roky dozadu (+ CentOS s uz vtedy pomerne starym jadrom).
Kazdopadne dal som mu druhu sancu a zatial v pohode - cca dva roky bez jedineho problemu jak na domacom serveri tak aj na notebooku (aj ked je pravda, ze podobna katastrofa ako vtedy sa zatial odvtedy nestala).
Kadopadne pre istotu som si spojazdnil pravidele zalohy do cloudu ;-)
Koukam ze nejsem jedinej co na btrfs prisel o data. Moje chyba, ze sem si tehdy neprecetl v dokumentaci, ze raid "zatim" nedoporucujou (i kdyz ficura uz byla implementovavna a btrfs oznaceno za stabilni). Po teto skusenosti sem nad btrfs vzteky zlomil hul a vratil se k zfs.
btw nemuzu se zbavit pocitu, ze (z jistejch duvodu) ani zfs, ani btrfs neni "ten pravej" next gen filesystem pro linux. Osobne davam velkou sanci spis bcachefs. Ten projekt se slusne hejbe, na to ze to dela (zrejme) jeden clovek...
Mám podobnou zkušenost, za posledních x let se mi několikrát stalo, že po náhlé poweroff situaci mi už btrfs nenaběhl a neuměl se opravit.
Základní problém je ten, že v takovém případě offline nástroje typu btrfs check (btrfsck) s vysokou pravděpodností nepomůžou nebo na fs zůstanou chyby i po nouzovém namontování. Pak nezbývá než data vykopírovat (to naštěstí jde i když se mount nepodaří), zformátovat a nakopírovat zpět a doufat, že zkorumpovaných souborů bude co nejméně...
Takže za mně dokud Btrfs nebude mít pořádný offline opravný nástroj, tak není dobrý pro produkci. Osobně jsem přešel všude kde to šlo na ext4 a nemám problém. Samozřejmě mi schází snapshoty a další vymoženosti, ale halt co se dá dělat. Btrfs mi zůstává na domácím notebooku, který nepřenáším a kde nehrozí díky baterce poweroff a tam běží spolehlivě už celá léta. Ale na nějaký NAS nebo přenosný disk nebo server bez baterky přímo v racku bych to po tomhle bohužel už nedal...
že zkorumpovaných souborů bude co nejméně
Trochu off-topic, ale poté, co dnes na titulní stránce iDnes citují mluvčí České advokátní komory: "Kdo chce psa být, hůl si najde" jsem trochu napružený.
"corrupt(ed)" má dva české významy: poškozený/porušený a zkorumpovaný.
Ačkoliv to "zkorumpovaný" má původ ve stejném latinském slově, v češtině má význam výhradně úplatkářský. Takto to tvoří větu, kterou si musíte zpětně převést do angličtiny a pak teprve dává smysl. Něco jako překlad "tvé oči září" = "your eyes september".
Nebe buď milostivo těm, kdo angličtinou nevládnou.
Doufám, že nepíšete dokumentaci pro uživatele.
15. 1. 2020, 08:06 editováno autorem komentáře
Překlad nebo pochopení je snad jasné z KONTEXTU dané informace. Apropos zkorumpovaný soubor je skoro něco jako zkorumpovaný politik, navenek se tváří korektně a správně, ale uvnitř může být zcela prohnilý a zákeřný. Podobně jako nějaký dokument, kde důležitá část, kterou zrovna potřebujete schází nebo je chaoticky něčím proházená nebo vám dokonce způsobí pád aplikace, která ho otevřela...
Překlad nebo pochopení je snad jasné z KONTEXTU dané informace.
To ještě není důvod používat tam slovo s jiným významem. Kdyby tam bylo napsáno podmáznutý soubor, ošklivý soubor nebo třeba hrubý soubor, z kontextu by čtenáři asi také došlo, že tím bylo myšleno „poškozený“. To ale ještě neznamená, že je v pořádku psát jako Hotentot.
To je jako kdybyste tvrdil, že je to samé, když někdo zastaví vodu a vyřízne na vodovodním potrubí část, aby tam mohl vložit odbočku – a když někdo překopne natlakované vodovodní potrubí krumpáčem, protože si myslel, že vede někde jinde. V obou případech je tam přece díra na vodovodním potrubí, že…
Pořád v tom „náhlá poweroff situace“, „zkorumpovaný soubor“, „nehrozí poweroff“, „zkorumpovaný soubor“ a chybějících čárkách hledám ten humor, a pořád ho nenacházím. jestli ono to nebude tím, že „udělat si legraci“ předpokládá záměr. Na tom, že někdo píše jako prasátko, nic humorného není…
Já vám váš názor neberu, nicméně můj názor je, že se nejednalo o humor werichovského typu. To je totiž humor, kterého si je autor vědom, vytváří ho záměrně a pracně. Pokud nebudu na ulici dávat pozor a šlápnu do psího ho…, někoho to možná pobaví, ale je to zcela jiný humor , než humor Werichův.
Dám vám i takovou pomůcku, jak to rozlišovat. Humor je založený na protikladech, je to způsob, jakým se mozek vyrovnává s tím, že se dozvídá protichůdné informace. Myslím, že tu radost z humoru a úlevu cítíme pro to, že mozku konečně dojde, že ty protichůdné informace nemusí nijak řešit. Všimněte si tedy, že Werichovy texty jsou vybroušené, nenajdete tam pravopisné chyby, není to žádný ledabylý text. Právě proto pak působí vtipně, když se v tom textu najednou objeví něco, co tam nepatří – vznikne tam potřebný kontrast, rozpor. Pokud někdo naopak plete i/y, mě/mně, velká písmena raději vůbec nepoužívá a čárky rozmisťuje náhodně, nemůže dělat humor tím, že napíše vyjmenované slovo s měkkým i. Protože tam nevznikne potřebný kontrast, rozpor, není tam nic překvapivého – když každá předchozí věta obsahovala alespoň jednu pravopisnou chybu, to chybně napsané vyjmenované slovo mne nijak nerozhází, není tam žádný rozpor, který by mozek potřeboval vyřešit úlevným humorem.
Slovně-překladová hříčka "zkorumpovaný soubor" není závislá na tom, jestli je autor nepořádný v pravopisu, nebo třeba i dysortografik. Hledáte-li kontrast či protiklad, tak ten spočívá v tom, že autor ukázal znalost provázání češtiny a angličtiny. Vybral pro překlad slovo, které je zpětně přeložitelné správně, ale dopředný překlad neodpovídá.
Opravdu si myslíte, že pan Dvořák nezná význam českého slova "zkorumpovaný"?
PS: Vtip Jeníka Chodiče nespočívá v kontrastu se zbytkem textu. Jeník Chodič je mile vtipný i bez kontextu. Jeho vtip spočívá v tom, že jej lze přeložit do angličtiny jen jedním způsobem. Werichovština jde samozřejmě ještě o jeden krok dál, kromě překladové hříčky si hraje i se samotnou češtinou - Johnnie-John-Jan-Jeník, Walker-Chodec-Chodič, ale mechanismus je stejný jako u zkorumpovaného souboru.
PPS: Pokusím se nad sebou zamyslet. Měl bych na sobě zapracovat abych uměl lépe rozpoznat, co je vtipné.
16. 1. 2020, 23:46 editováno autorem komentáře
autor ukázal znalost provázání češtiny a angličtiny
Nebo neznalost překladu z angličtiny do češtiny.
Opravdu si myslíte, že pan Dvořák nezná význam českého slova "zkorumpovaný"?
Ne, nemyslím. Myslím si, že v textu úplně zbytečně používá anglicismy, aniž by si uvědomil, že jím vytvořené slovo je normální české slovo, které má ovšem jiný význam.
Vtip Jeníka Chodiče nespočívá v kontrastu se zbytkem textu. Jeník Chodič je mile vtipný i bez kontextu. Jeho vtip spočívá v tom, že jej lze přeložit do angličtiny jen jedním způsobem.
Jsou tisíce slov, které lze do angličtiny přeložit jediným způsobem, a nic vtipného na nich není. K pochopení Jeníka Chodiče ale potřebujete znát kontext – totiž že Johnie Walker v angličtině má konkrétní význam, je to ustálené spojení, které má určitý význam. A teprve pak můžete pochopit vtip, který spočívá opět v kontrastu toho, že poeticky přeložíte slova, která se vůbec překládat nemají. Proto to není Jan Chodec, protože to by byl jen obyčejný překlad a ten kontrast by tak nevynikl, ale je to Jeník Chodič, aby vynikla ta absurdita, že si dal záležet s překladem něčeho, co vůbec přeloženo být nemá.
Já jsem si ten myšlenkový pochod představil: poweroff situace poweroff situace, nehrozí poweroff nehrozí poweroff, corrupted soubor zkorumpovaný soubor.
Respektuji váš názor, že si Václav Dvořák v tomto jednom případě chtěl hrát s jazykem. Ale osobně zastávám názor, že se případ, kdy se mu prostě nechtělo k anglickému slovu hledat český výraz, vyskytuje v jeho komentáři ne dvakrát, ale třikrát. To je vše.
Ale osobně zastávám názor, že se případ, kdy se mu prostě nechtělo k anglickému slovu hledat český výraz, vyskytuje v jeho komentáři ne dvakrát, ale třikrát.
Ta hříčka (poškozený=>corrupted=>corrupt=>zkorumpovaný) se odehrává u mě v hlavě, ne v hlavě pana Dvořáka. Je klidně možné, že ji vytvořil zcela nezáměrně. Na vtipu jí to neubírá.
toto sa uz, myslim, dost zlepsilo - neocakavany poweroff som mal doma za posledny rok minimalne 4x (vypadok prudu v celom baraku). Server zakazdym nabehol bez problemov a bez akehokolvek mojho zasahu a bez straty dat.
Mozno som mal len stastie, ale skor si myslim, ze na tom v poslednej dobe dost tvrdo makaju. Ale aj tak bude zrejme chvilku trvat kym to dosiahne spolahlivost ext4...
To je střet dvou filozofií vývoje v OSS.
Buďto produkt dáte k dispozici hotový, třeba (zatím) s méně funkcemi. Ale proč by pak měl někdo používat Btrfs, kdyby nic moc nového nepřinášel?
Nebo poskytnete kód nehotový a ostatní by měli počítat, že existují určitá rizika. Zde ale nastupuje jistý masový fenomén. O Btrfs se hodně píše a čtou o něm jak znalejší, tak laičtější uživatelé. Ti znalí už vědí, jaká rizika s filesystémem souvisí, jak je třeba důležité znát zkušenosti z praxe (a ne zkušenost od laika, který má doma jeden, dva disky), ... Bohužel laik nedovede posoudit, která informace a který článek popisuje jen vlastnosti a který opravdu fundovaně vypovídá o nějaké rozsáhlejší praktické zkušenosti.
U Btrfs se stalo, že ho v praxi začaly používat masy, které ale využívají jen omezený subset funkcí a vytvářejí jen omezené provozní situace. Když náhodou narazí na nějakou méně obvyklou situaci, může přijít závada.
Nyní následuje fáze deziluze. Stejně lehce, jak laikové Btrfs začali používat, stejně lehce ho hodí i přes palubu. To je pro Btrfs zbytečná a možná i nebezpečná situace. Mohl by ustrnout, pokles popularity demotivuje vývojáře atd. atd. A celé jen kvůli "pár" příspěvkům: "mně to funguje super" a úvaze "tak to zkusím taky" a posléze: "mně to spadlo" a "mně taky".
O Btrfs vypovídá hodně, že distribuce si na něj netroufly přejít, nebo maximálně s umožněním jen několika základních variant nastavení. Takového přístupu by se měly držet masy a z tohoto vybočovat jen postupně a počítat s tím, že je potřeba ostatní situace doladit.
To je správná otázka. I v open source už je obrovská konkurence. Když odhlédneme od licenčních šarvátek, tak technicky vzato nemám (zatím) nejmenší důvod používat Btrfs s chybami oproti poměrně dost vyladěnému ZFS, do kterého kdysi korporace nalila spoustu peněz. Na jednu stranu je open source dnes značně bohatší o příspěvky kódu, který platí firmy. Na druhé straně to bere ostatním chuť testovat cokoliv jiného (nového) a autorům to bere chuť něco vyvíjet (nikdo nechce slyšet jen kritiku). Já tomu říkám "ochočení open source". Velké firmy tím zvládly nasměrovat uživatele a v důsledku i vývojáře směrem, který je neohrožuje.
Pokud zůstaneme u Btrfs / ZFS, tak co mi zcela chybí jsou např. funkce pro multitiering (neřku-li automatický tiering), rozšiřování za chodu, odlišné "geometrie" dat ve stejném poolu atd. To vše už enterprise segment má, ale opensource se doposud babrá s Btrfs, které dohání to, co mělo ZFS před léty a které Oracle odhodil s tím, že už ho zveřejnění neohrožuje.
Narocnost na zdroje.
Ano, to je pravda, ale cena HW klesá, takže to možná v budoucnu nebude taková překážka. iX systems nedávno zveřejnil svoji práci na značném snížení nároků na deduplikaci.
Mně třeba chybí na ZFS možnost offline deduplikace.
Nemoznost zrusit nektere nakonfigurovane veci.
Ano, to je pravda, osobně to připisuju tomu, že je právě větší zájem na stabilitě, než umožnit něco rizikového.
Nesnasi raid radice.
Přímo RAID řadič nedává se ZFS (ani Btrfs) moc smysl, protože pak filesystem ztrácí cennou informaci o rozložení dat na discích a možnost s tím hospodařit. Nicméně, na ZFS RAID řadiče používám v JBOD konfiguraci, využije se pak cache řadiče a jeho BBU.
Určitě je co vylepšovat nebo překonávat - zmínil jste ty změny konfigurace, já zmínil offline deduplikaci, multitiering, automatický tiering, ..., souhlas. Jen nevím, jestli je reálné to vyvinout na Btrfs, protože jeho komplikovanějších funkcí se ti, co by je potřebovali, bojí.