Co se týče ZFS, jen bych upřesnil rozdíl mezi ARC a ZIL. ARC v žádném případě nezvyšuje rychlost zápisu, protože se jedná o čtecí cache, která má v ideálním případě více úrovní ARC,L2ARC (napřed RAM, pak nejlépe SSD). Jejím cílem je odstínit fyzické čtení z pomalých rotačních disků. Proto si vezme v defaultu nejméně polovinu, celé, systému dostupné RAM. Pokud to nevyhovuje, lze limit RAM snížit a ZFS bude číst další data navíc ze sekundární L2ARC, tedy třeba SSD, pak teprve disky.
Ve směru zápisu se jedná o ukládání tzv. ZFS Intent Logu (ZIL). Do ZIL se obvykle pouze zapisuje a obvykle se z něj NEčte, slouží pro případ výpadku. Data jako taková jsou postupně na pozadí zapsána na pomalý disk.
Pokud do ZFS přidáme SSD, zvyšuje se tím rychlost synchronních (těch, kde proces vyžaduje potvrzení o zápisu) zápisů na disk a vytváříme tak další strukturu zvanou SLOG.
ZFS sice v současnosti nemůže z licenčních důvodů být přímo v jádře, ale, protože ve většině distribucí lze doinstalovat jako balík, za spravedlivé bych považoval dát link na FORK původní sunovské verze http://open-zfs.org/wiki/Main_Page
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í.
Myšlena (a zdůrazněna) licenční nekompatibilita s kernelem, která brání tomu, aby se ZFS začlenilo do kódu jádra. ZFS má jinou licenci, po jeho začlenění do kernelu by nešlo kernel vydat pod stávající GPL.
Ale jinak si samozřejmě v Linuxu můžete spoustět software s "libovolnou" licencí, ať už přísnější nebo volnější než je GPL. A přesně takhle to zvolili u Ubuntu - balíčky s kernelem je pod jednou licencí, balíčky se ZFS pod jinou licencí.
14. 1. 2020, 10:33 editováno autorem komentáře
Předně by musel existovat někdo, kdo cítí, že do jeho práv bylo zasaženo. O ničem takovém zatím nevím.
Přístup Canonicalu je logický, je zbytečné hledat problémy tam, kde pravděpodobně ani nejsou. Právní společnost musí umět respektovat práva druhého a druzí musí umět respektovat práva prvního. To jinak, než postupným vyjasňováním to nejde.
Canonical dělá ve skutečnosti pro OSS velkou službu, to vyjasnění je potřeba a málokomu se do něj chce.
Ještě bych zmínil Microsoft ReFS: https://en.wikipedia.org/wiki/ReFS, ten patří do přímého porovnání s Btrfs a ZFS.
Ve výčtu ostatních filesystémů stojí ještě za zmínku Ext4, XFS a exFAT.
Když už je rozlišován Ext2 - Ext4, pak u NTFS je dlužno dodat, že už je v páté, taky zpětně kompatibilní verzi.
14. 1. 2020, 06:42 editováno autorem komentáře
Ahoj, mě by zajímalo, jak technicky fungují snapshoty. Chápu, že je ukládán ne celý soubor, ale pouze jeho změna. Mě by ale zajímalo, jak je to právě uložené. Jako další "soubor" nebo nějak jinak?
Ptám se, protože před ukotvením se na Manjaro jsem zkoušel openSuse s Btrfs ale bylo to nešťastně nedomyšlené. Za cca 2 dny nastavování systému, instalací programů aj. se mi samy udělaly stovky snapshotů což vedlo k téměř totální nefunkčnosti systému - bylo to pomalé ve smyslu, že úkon, který trvá normálně vteřinu běžel několik minut. Moje hypotéza byla právě přemíra snapshotů, což se mi potvrdilo, když se mi podařilo v rescue příkazem snapshoty smazat (trvalo to několik hodin). Pak zase systém běžel normálně. No stejně mě ale openSuse zklamalo v jiných věcech, takže jsem u něj nezůstal.
Každopádně HDD bylo obsazené sotva ze 1/4, tedy mi přišlo, že se ty snapshoty ukládají jaksi jinak...
Když zapíšete změnu do souboru, dotčený blok se zapíše jako nový do volného místa, a starý blok s původním obsahem se zahodí, pokud na něj už neukazuje jiná reference (to je to copy-on-write). Když uděláš snapshot, jednoduše se na bloky dotčených souborů udělá další reference, takže při nějaké změně nejsou smazány, protože na něj ukazují reference ze snapshotů.
Mít stovky snapshotů něčeho většího (jako třeba rootfs) je špatně, na to to není dimenzováno. To se v openSuse netrefili :)
Dovolím si nesouhlasit s oběma komentáři. Ano, na normálním systému jistě člověk dělá málo změn, problém je, že to snapshot udělá i při otevření nastavení nebo yast (aspoň před cca půl rokem to tak bylo) a při spoustě dalších příležitostí. Jo a taky defaultně to dělalo časové snapshoty, což může vyústit v to, že uživatel, který toto neví, tak snapper nemusí vůbec otevřít a dopadne jak já.
A ano, nedůležité snapy je možné smazat přes GUI, jenže když se vám najedou sekne systém a vy nejste schopní se vůbec dostat do DE, tak je to trochu na nic.
Největší problém ale vidím v tom, že se nastavení tvorby snapshotů nedělá na jednom místě. Už nevím jestli šlo něco nastavit ve snapperu, ale část nastavení se dělala přes příkazovou řádku (což osobně nevidím jako moc příhodné) a část nastavení se musela hledat v konfiguračních souborech různých aplikací, jejichž spuštění automaticky udělalo snapshot, už je už úplně mim mísu.
Není to přepis na místě. Starý soubor se buď zahodí a pak se zbylý prostor může otrimovat nebo zůstane jako součást snapshotu (dokud se ten nesmaže). SSD to neopotřebovává, to mohu po 5 letech konstatovat (wear leveling na úrovni procent) i když disk používám k práci denně a snapshoty nezabírají žádný velký prostor.
Kdyby btrfs neměl jiné nectnosti (za mně hlavně poweroff smrt), tak tohle je jedna z jeho největších výhod a je to perfektní.
Sice se z toho strilet urcite nebude, ale:
1) macOS ma od roku 2017 APFS
2) HFS ja prastary FS. Podporu formatovani a i jeho zapisu Apple zahodil v roce 2009 a podporu cteni zahodil loni.
Takze spise nez "HFS a HFS+" by tam melo byt "HFS+ a APFS".
Zdravim, na zacatku v prehledu systemu mate za sebou 2x ext3, asi tam melo byt 1x ext3 1x ext4.
Docela bych ocenil takovou pripadovou studii: mam ext4 a ted dam btrfs. Co mi to prinese v pripade napr. desktopu a notebooku? Zalohovat musim tam i tam, zpatky v case se nevracim, bo pouzivam git, zvetsit/zmensit ext4 umim. Ukol by stal - ukazat, ze je tam neco, co jeste nevim, ze nutne potrebuju.
Kdysi (mozna i ted) se hodne pouzivalo LVM, ale neprisel jsem tomu na chut. Existuje to jeste, ma to co rict k nekterym vlastnostem brtfs?
Diky
Co třeba - chci otestovat balík, jehož instalace do systému zanese spoustu bordelu a ne tak úplně mu věřím.
Snapshot, instalace, rollback - bez bordelu v systému?
To samé v případě upgradu - něco se rozbije, existuje jednoduchá bezbolestná cesta zpět.
Takhle mi to alespoň funguje u ZFS. Btrfs jsem párkrát zkoušel, jednou jsem přišel o data, pak jsem už díky zálohám při následujících pádech o nic nepřišel, ale do produkce to mělo daleko. Možná už je to bezpředmětný, ale ztracená důvěra se těžko získává zpět...
Na tohle to funguje skvele, problem nastane, kdyz ten system chces updatovat. Vypnuti sync (fsync) je u balickovaciho systemu skoro nutnost (o pripadny problem a rollback by se ti mel teoreticky postarat fs). Skoro si rikam, jestli by na tomhle principu nemel fungovat cely balickovaci system - proste si nestahnes balicek x, ale kompletni subvolume/snapshot toho balicku, ten se umisti do slozky a hotovo. Upgrade bude fungovat tak, ze se proste nahreje jiny snapshot a pokud se budes chtit vratit k predchozi verzi, tak to proste jednoduse prepnes zpatky.
LVM se pouziva samozrejme i ted ;-) napr. *buntu/Mint a myslim i Debian ho pouzijou automaticky, kdyz se zvoli "sifrovani disku", nebo ho pri instalaci muze vybrat rucne uzivatel i kdyz nechce sifrovat....
pouzivam LVM vsude spoustu let, vyhoda je:
- neni treba hejbat oddilama kdyz chci nejaky zmenit
- zvetsit oddil lze za behu systemu i kdyz jde o systemovej a/nebo pripojenej oddil
- v LVM VolumeGroup nechat volne nevyuzte misto ktere lze podle potreby pridat stavajicim oddilum, nebo vytvorit docasne dalsi oddil
- lze pouzit snapshot, udelat zmenu v systemu, vyzkouset nejakou neoverenou instalaci balicku a kdyz bude problem, vratit zpet ("akorat" to neni stavene na vetsi mnozstvi snapshotu jako btrfs)
- pri pouziti sifrovani (LUKS) se s LVM odemknou vsechny oddily v LVM, pri sifrovanych beznych Ne-LVM oddilu se musi kazdej odemknout sam (pokud ty to bylo naopak chtele, lze udelat LVM primo na disk a LVM az na vybranejch LV oddilech)
- v LVM VolumeGroup nechat volne nevyuzte misto ktere lze podle potreby pridat stavajicim oddilum, nebo vytvorit docasne dalsi oddil
A právě tohle mi na LVM vadí. Ta NUTNOST nechávat nevyužité místo. Nemožnost jednoduše jedním příkazem, trvajícím zlomek sekundy, zmenšit jeden filesystém a ihned to přidělit pro jiný fs ze stejného VolumeGroup.
V ZFS je v poolu místo sdílené přes všechny filesystémy, pokud není nastaveno jinak (quota, rezervace). Na to, abych si vytvoříl nějaký dočasný filesystém, si nic nemusím extra rezervovat.
Já čekám na tu podporu Raid 5 v btrfs, aktuální use case:
- mám 4x2G disky v MD Raid 5, na tom mám GPT + ext4
- pokud chci přidat disk, tak musí mít 2G, a musí se provést kompletní rehash celého diskového pole
- pokud chci změnit velikost disku, musím vyměnit všechny disky
- pokud bych tam měl btrfs, budu moct přidat disk libovolné velikosti, přeskládají se pouze data, která jsou potřeba, a stále mi zůstane výhoda Raid5, že může bez ztráty dat havarovat libovolný disk.
- oproti tomu u ZFS existující vdev rozšířit vůbec nemůžu, můžu jen přidat další vdev, ale zase ztrácím redundanci, nebo můžu nahradit všechny disky většími+expand, ale to jsem tam kde jsem byl s MD
Výhoda btrfs se výrazně projeví při práci v RAIDu (zejména kombinace disků různých kapacit, jednoduchý přechod z režimu RAID na režim single ap). Nicméně ďábel je právě v systémových detailech používání Raidu. Pokud disk zemře je tady pro problém s bootem, pokud nejsou všechny zbývající disky raidu bootovatelné - ten existuje i u mdadm ale nyní se ten problém s přechodem na UEFI a BRUB2 a GPT zvětšuje a řekl bych i znepřehledňuje, protože disk s příznakem missing v systému zůstává, náhrada disku příkazem replace není zrovna krystalicky jasná. Pokud to udělám v degradovaném módu jde to nějak udělat. Problém s bootem a předcházení pádu systému po restartu řešil kdysi tento článek http://www.gattis.org/Work-and-Tech/operating-systems-and-applications/unix/file-systems/btrfs-raid-boot .Ale mezitím přišel UEEFI, GPT a GRUB2 a nevím zda tohle ještě platí. Kousne seriál i do totoho kyselého jablíčka? Pokud se těmto instalačním problémům seriál vyhne, asi moc k rozšíření btrfs nepřispěje.
problem byl(?) MYSLIM v tom ze btrfs raid1 pri vypadku 1 disku z 2 hodil pole do readonly a pri rebootu uz nebylo pripojitelne vubec dokud se neprovedla vymena disku a vyreseni, u mdadm je stale readwrite a lze i nastavit (re)boot v degraded rezimu v rezimu...
druha vec s tim neprimo souvisejici, ze btrfs raid1 na vice nez 2 disku nebyl regulerni raid1 mirror, protoze data zrcadli JEN na 2 disky, nikoliv na vsechny v raid1 (jako mdadm), tohle uz nejaka novejsi verze btrfs tusim umoznuje aby to delalo opravdovej mirror pres vsechny, jen uz taomu nerika raid1
Asi by bylo dobré uvést, že zatímco obvykle se pod RAID 1 myslí to, že každý blok je zapsaný na všech zařízeních v RAIDu, u btrfs se pod RAID 1 myslí „každý blok alespoň na dvou zařízeních“. U dvou disků je výsledek stejný, u třech disků budou u obecného RAID 1 data zapsaná třikrát a přežijí výpadek dvou disků, u btrfs RAID 1 budou data zapsána dvakrát, při výpadku dvou disků přijdete o část dat, ale budete mít kapacitu 1,5 násobku kapacity disku (pokud jsou všechny tři stejné).
A já ještě doplním, protože zde bylo srovnání, že ZFS to nazývá jako RAID-Z1, RAID-Z2 a RAID-Z3. Navíc jde na volume nastavit ještě parametr copies, který zajistí, že stejný blok je uložen x-krát. RAID-Z zajišťuje ochranu před havárií média, zatímco copies zajišťují ochranu integrity. Pokud se některý blok poškodí a nesedí checksum, je načtená jiná kopie se správným checksumem.
Takže raid-z3 + copies=2 zajistí, že stejný blok je uložen šestkrát: dvě kopie rozložené na třech různých discích.
Už tady někdo zmínil Synology a jejich BTRFS, které pro RAID5 a 6 vývojáři ještě loni nedoporučovali do provozu, tak jen trochu do mlýna, protože já zase řádím s QNAP NASkami :)
Proč se QNAP drží s vývojem ext4 a nechtějí btrfs: https://www.qnap.com/solution/qnap-ext4/cs-cz/
ALE! Co je aktuálně hodně zajímavé (a těším se na to), je přicházející QTS hero (QTS se ZFS!): https://www.qnap.com/qts-hero/cs-cz/
Btrfs jsem použil na zálohovacím disku právě pro snadnost vytváření snapshotů. Výsledkem ovšem bylo, že když se nyní po zaplnění disku začaly staré snapshoty mazat, tak proces btrfs-cleaner žral 100% CPU a k tomu kernel vyžral všech 16GB fyzické paměti, ačkoliv jindy použije tak 2,5Gb, kolem 14GB na cache a zbyteček nechá volný. Systém si začal stěžovat, že má nedostatek paměti a odstřeloval různé démony, což skutečně nepotěšilo. Restart stroje (!!!) způsobil, že se to celé opakovalo.
Přidat 32GB swapu a nechat běžet server v degradovaném stavu nepomohlo ani trochu. Dva dny tam ten btrfs-cleaner něco kutil, dva dny si server stěžoval na nedostatek paměti (16GB fyzické a 32GB swap. Vzhledem k tomu, že samotný disk s Btrfs má 280GB, je to docela průser.
Takže moje zkušenost je poměrně mizerná.
Napad BTRFS sa mi zo zaciatku velmi pacil. OpenSuse to poduzije v default instalacii uz roky. Realizacia sa mi ale nepacila ani trochu. Narazil som na hromadu nedorobkov v integracii tohto FS do OS.
1) Vystup mount a df je necitatelny. Zasvini sa to mrakmi moutov. Mount zdroj neobsahuje informaciu o pouzitom subvolume. df pise v kazdom riadku tie iste statistiky. Ocakaval vy som, ze minimalne "used" bude obsahovat informaciu len o vyuziti disku toho daneho subvolume (+porcia snapshotov) a nie celeho fs.
2) 100% CPU load - Pri nejakych upratovacich taskoch to dokazalo odstavit aj 4jadrove i7 na cele minuty. Pomohlo vypnut quoty. Ale len kym clovek nenarazil na dosledok:
3) Snapshoty nic neupratuje. Pravidelne aktualizacie a ine tasky vyrobia kludne aj 5-10 snapshotov za tyzden pri normalnom pouzivani desktopu. Za dva mesiace sa cely disk zaplnil snapshotmi. A clovek len kuka, ze to nejak blbne. Vazne si musim vypratavat snapshoty rucne? Uz aj winy si vedia svoj bordel aspon z casti upratat same.