Názory k článku Fedora 33 přejde na Btrfs
-
Tak ZFS je pro Fedoru (a celou řadu dalších distribucí) no-go kvůli licenčním důvodům. Že ZFS není součástí hlavního stromu jádra a upstreamoví vývojáři na něj neberou ohledy, je potom docela nepříjemný praktický nedostatek.
ZFS je dneska rozhodně vyzrálejším souborovým systémem, ale nečekám, že by se ta dvě výše zmíněná omezení v budoucnu odstranila, takže z dlouhodobého hlediska je myslím lepší vsadit na Btrfs.
-
ZFS je dneska rozhodně vyzrálejším souborovým systémem, ale nečekám, že by se ta dvě výše zmíněná omezení v budoucnu odstranila, takže z dlouhodobého hlediska je myslím lepší vsadit na Btrfs.
Ony jsou oba dva stejně málo perspektivní. ZFS je "vyzrálejší", ale mimo dobu. Enterprise storage řešení nabízejí už o dvě generace víc funkcí, než pojímá ZFS (ostatně, jinak by ho asi ani neuvolnili pod CDDL) a vývoj nejde moc dopředu. Btrfs zase trpí tím, že se zatím nenašla žádná síla, která by ho stimulovala tímto směrem. Takže tu máme ZFS bez perspektivy, a Btrfs, které se vyvíjí spíš směrem k užití pro desktop a malé servery, než enterprise storage.
-
Například ZFS storage appliance:-DDD ? Není dostatečně enterprise? Ani v té největší konfiguraci?
Třeba u hitachi si za každou ptákovinu extra zaplatite. A replikace je jedna z větších položek.
V česku obecně velké storage systémy nejsou protože tu pro ně prostě není trh. Není potřeba.
Kdo má tady stovky peta živých dat a několik exa v archivaci? -
btrfs je jedinej fs, u kteryho sem opravdu prisel o data (a nebyl sem sam). A to je u "stabilniho" fs nepripustne. Ja mam takovej dojem, ze kvuli nejasnostem ohledne licencovani zfs byl btrfs az prilis "tlacen" kupredu, aby tady skratka rychle "neco bylo", kdyby to snad s zfs uz dal neslo...
Pokud bych ja na neco mel vsadit, pak by to nebyl zfs ani btrfs. Spis neco uplne jinyho, treba bcachefs. Kent jiz poslal patche do lkml, a ja si klidne pockam i nekolik let, nez si bcachefs najde cestu do kernelu...
-
Filip JirsákStříbrný podporovatelbtrfs je jedinej fs, u kteryho sem opravdu prisel o data (a nebyl sem sam). A to je u "stabilniho" fs nepripustne.
I u stabilního souborového systému samozřejmě můžete přijít o data. Žádný souborový systém neumí zázraky, takže například pokud odjede hardware nebo něco pokazí uživatel, souborový systém to nezachrání. A vy jste nenapsal nic o tom, proč jste přišel o data – jestli to třeba nebyla vaše chyba. -
k3dARStříbrný podporovatel@Filip Jirsák
rozdil je ten ze u EXT4 je e2fsck normalni podporovanej/doporucovanej nastroj na opravu filesystemu, u BTRFS od btrfsck tvurci odrazuji a doporucuju to az jako posledni moznost...
dalsi vec je ze nekolikrat sem od zastancu BTRFS cetl radu pro nekoho komu se BTRFS naboril, ze nejlepsi "reseni" je vykopirovat data (pokud to jde), zformatovat a vratit zpatky (pokud neslo, tak ze zalohy)
-
S tím nesouhlasím. Např. u Ext4 je možné i velmi velké poškození vyřešit offline checkem (tj. v případě že se nedaří fs normálně namontovat). Něco takového je u Btrfs stále nemyslitelné a jediné řešení je vykopírování obsahu a kompletní obnovení. Fs bez možnosti nouzové opravy je podle mně celkem nanic.
Osobně jsem po několika takových případech raději přešel i za cenu časových nákladů a ztráty vymožeností jako cow snapshoty nebo subvolumes zpět na Ext4, kde jsou věci jasné a jisté... Btrfs by bylo bezkonkurenčně skvělé, kdyby ovšem v sobě stále nemělo těch několik čertových kopýtek. -
Filip JirsákStříbrný podporovatel
Na nesouhlas máte právo. Ale nenapsal jste nic, co by bylo v rozporu s mým komentářem.
-
Filip JirsákStříbrný podporovatel
Celé vlákno začalo konstatováním „přišel jsem o data“, bez jakýchkoli dalších podrobností. K tomu lze akorát konstatovat, že někteří uživatelé dokáží přijít o data s libovolným souborovým systémem.
Souborové systémy se samozřejmě mohou lišit svou spolehlivostí, ale tvrzení „se souborovým systémem X jsem přišel o data“ o tom souborovém systému nevypovídá nic.
-
ale tvrzení „se souborovým systémem X jsem přišel o data“ o tom souborovém systému nevypovídá nic.
Filipe, to je zkratka v kontextu. Kontextem je Btrfs a jeho pověst nespolehlivosti. Ta pověst je podle všeho postavená na skutečných základech - některé chyby jsou známé, je známý i stav R5/R6, ... Myslím si, že není žádné velké křivdění říct, že Btrfs není dostatečně spolehlivý. Podle všeho je spolehlivý určitý subset funkcí, které se využívají.
-
nextsuxStříbrný podporovatelVidíš a já přišel o data na XFS, protože jsem si moc brzo pořídil dvoujádrové CPU a moc paměti (bug se mi k tomu už nedaří najít). Btrfs používám na serverech i desktopu mnoho let (5+) a neměl jsem problém.
Prostě 100 lidi, 100 zkušeností. Já se řadím k milovníkům btrfs a ze srdce nenávidím XFS ¯\_(ツ)_/¯
17. 7. 2020, 23:37 editováno autorem komentáře
-
Ondra Satai NekolaZlatý podporovatel100 lidí, 100 zkušení.
Ale otázka je, zda 95 z těch zkušeností neříká to samé.
-
Na Btrfs nepřechází celá Fedora, ale pouze edice Workstation a další desktopové spiny. Red Hat řeší souborový systém především v serverových nasazeních, kde je upstreamem RHELu Fedora Server a CoreOS. Tyto edice i nadále zůstávají na XFS a jsou tak v tomto s RHELem "na jedné lodi".
Přechod u Workstation na Btrfs byl iniciovaný komunitou, protože se to v daný okamžik ukázalo jako nejlepší řešení. S Red Hatem a jeho plány kolem souborových systémů to nemá nic společného. Pokud budou nějaké problémy s Btrfs, bude poskytovat vývojářské síly na jejich řešení Facebook, který taky patří mezi velké přispěvatele do Fedory a na Btrfs dlouhodobě sází.
-
Ve Fedoře 32 AFAIK ne, ve Fedoře 33 se to řeší, už existují patche, které probublávají do vývojové Fedory, a myslím, že ve finální F33 bude Silverblue nad Btrfs fungovat bez problémů.
-
Některé distribuce sice přecházejí na Btrfs, ale čistě přepnutím defaultního FS, a pro uživatele to nemá tolik výhod.
Rád bych věděl, jestli Fedora Workstation plánuje integrovat do OS všechny možné nástroje a featury, tak, aby třeba při každém `dnf něco` byl vytvořen snapshot, aby šly snapshoty spravovat nějakou šikovnou aplikací (já osobně rád klikám myší), a aby šlo v tom grubu z menu nabootovat do staršího snapshotu....
A pokud je pravdou, že Btrfs někdy mívá problémy se stabilitou, tak právě široké nasazení spíš vytvoří podmínky a tlak na jejich dořešení. Prolomí se tím problém slepice a vejce.
-
DNF už snapshoty nad Btrfs umí, stačí doinstalovat modul dnf-plugin-snapper a začít používat. Jestli to bude mít i nějaké GUI? Těžko říct, plány zatím nejsou, ale to je hlavně kvůli tomu, že ta změna proběhla rychle. Dělalo se to hlavně kvůli problému s fixní velikostí oddílů v Ext4, kdy se lidem stávalo, že jim došlo místo na /, zatímco měli hromadu místa v /home, a naopak. O tom, jak využít ostatní výhody, které se s přechodem na Btrfs naskytly, se zatím diskutuje.
-
RaviseStříbrný podporovatel
Vím, že jsem na ten problém s Grubem2 v uefi bootování narazil a pak jsem z kořene vydělil kousek disku pro /boot. Od té doby jsem to nezkoumal, takže díky za info, při příští reinstalaci to zase zkusím.
-
Jak je v tom linku, nejde zapisovat primo do bloku toho env souboru. takze Vyresilo se to tak, ze na nejakem offsetu, co btrfs nevyuziva (0-1M) se ten env ulozi docasne nez system nabootuje, pak se to synchronizuje do /boot/grub2/grubenv. Offset kam se ten env uklada je konfigurovatelny, ja tu mam treba 'env_block=512+1', coz je 256KiB.
-
Když jsem před rokem a něco zkoušel OpenSuse, BTRFS se mi celkem líbilo, mám na mysli ty možnosti oprav systému. Hlavně to, že se dal systém nabootovat do "starší" verze. Bohužel se ukázalo, že to celé asi funguje tak, že když otevřete "něco co dělá samo snapshot" a že "toho" nebylo málo, tak se konfiguráky atp. prostě nepřepíšou, ale dělá se něco jako symlink na další soubor (myslím, že všichni známe technickou část, tak proto tak zjednodušeně). BOHUŽEL když těch symlinků je v řadě třeba 20, tak mě to udělalo to, že se systém bootoval a bootoval a nenabootoval. Oprava byla taková, že přes příkaz jsem smazal všechny snapy a pak to jelo v pohodě (tato oprava trvala několik hodin). Nejvíc mě pak naštvalo, že chybí jednotná správa snapů, takže to bylo tak, že jsem musel u každé aplikace, která snapy dělala automaticky toto rušit přímo v jejich konfigurácích.
Sečteno, podtrženo. Má to sice silné argumenty pro, ale v té době (a nevím jak teď) to nebylo doladěné a prostě je k tomu potřeba udělat pořádný GUI, kde všechno nastavíte a hlavně, který Vás upozorní na případné výkonnostní problémy, když už je těch snapů třeba 40. Protože u mě ten problém nastal velice nárazově.
-
U openSUSE existuje Snapper. Nějaká aplikace by měla využívat Snapper a ne si dělat snapshoty v jiném subvolume, jestli jsem to správně pochopil - v opačném případě by měla poskytovat vlastní nástroj na správu (ideálně včetně GUI).
Změna snapu nebo návrat na aktuální by mělo fungovat přímo přes Grub menu, takže mi není jasné proč by se měly ručně mazat nějaké symlinky.... Bylo to normální openSUSE a/nebo jen nepochopení fungování? -
Tak samozřejmě jsem měl výchozí nastavení po instalaci systému a právě Snapper jsem používal. PROBLÉM je právě v tom, že ve Snapperu můžete jednotlivé snapy "obhospodařit" a nastavit kdy se má snap udělat na základě daily, weekly... ale už ne, která aplikace (např. nastavení) může či nemůže vytvářet vlastní snapy. To musíte udělat v extra konfiguráku dané aplikace, jak jsem nakonec zdlouhavě zjistil.
Upřímně, šel jsem po tom jen z čisté zvědavosti. OpenSuse mě tak zklamalo, že jsem to vzal posléze pouze jako technické cvičení.
A ano, z grub menu to krásně funguje, jak jsem psal. Do té doby, než je těch snapů např. 50, jen proto, že si se systémem hrajete a několikrát něco někde nastavíte. Potom už nefunguje nic, prostě se systém téměř zasekne ve smyslu BRUTÁLNÍHO omezení čtecí schopnosti disku. Pak musíte čekat a čekat, zadáte příkaz, čekáte, zadáte příkaz, čekáte... než všechny snapy smažete - potom systém naběhl "jako nový".
Když nad tím teď tak znovu přemýšlím, tak mě napadá (velice zjednodušeně), že to vlastně funguje na bázi "superfragmentace". Jestliže to namísto přepsání souboru1, udělá soubor1 a jinde na disku změnasouboru1 a pak změna2souboru1 atd. atd., což samozřejmě po nějaké době vyústí v praktickou neschopnost HDD něco vůbec načíst. Vymazáním snapů se vlastně tyto "subsoubory" staly kompaktním celkem a proto se problém vyřešil. Nevím nevím, jestli je tohle ta správná cesta.
-
> Když nad tím teď tak znovu přemýšlím, tak mě napadá (velice zjednodušeně), že to vlastně funguje na bázi "superfragmentace". Jestliže to namísto přepsání souboru1, udělá soubor1 a jinde na disku změnasouboru1 a pak změna2souboru1 atd. atd.,
Áno, to je princíp Copy-on-write.
> což samozřejmě po nějaké době vyústí v praktickou neschopnost HDD něco vůbec načíst.
HDD áno, SSD nie. Pretože zariadenie musí seekovať, čo na HDD trvá, na SSD až tak nie (do určitej miery; prečítať jeden dlhý blok je stále rýchlejšie ako niekoľko malých).
> ymazáním snapů se vlastně tyto "subsoubory" staly kompaktním celkem a proto se problém vyřešil. Nevím nevím, jestli je tohle ta správná cesta.
Závisí od zariadenia. Pre SSD je to určite lepšia cesta, pretože CoW má bližšie k log-based systémom. Neprepisuje sa stále ten istý sektor, ale vždy nový, prázdny na konci. Výrazne to uľahčuje prácu FTL v SSD.
Pri rotujúcej hrzdi áno, cenou je pokles výkonu.
-
@bez přezdívky
Ono to ukazuje nevýhody užití Btrfs. Na HDD "zaplatíte" neúměrnou latencí, na SSD "jen" počtem zápisů. To samozřejmě není důsledek filesystemu, ale důsledek rozhodnutí využívat takovou funkcionalitu (snapshoty a s tím související podmínku CoW). Ani jedno nedokáže běžný smrtelník kvalifikovaně a dopředu vyhodnotit. IMO je to určené pro poloprofesionály, kteří umějí posoudit přínos vs. "cena". Možná se to v budoucnu změní, až se posunou možnosti SSD (ale zatím to tak moc nevypadá, když se tak dívám na trend SLC=>MLC=>TLC=>QLC).
-
Jasně, na tom ntb byl HDD, to jsem zapomněl zmínit :).
Já bych to viděl spíš, že ani tak nejde o typ disku, ale o to, co s tím diskem budete dělat. Myslím, že je to dobré na disky, kde máte data, chcete verzovat a ušetřit nějaké to místo a možná čas na zápis atd. Na systémový disk to moc není, protože si musíte hlídat kolik snapů máte v řadě, které zachovat a které smazat (nějaká poloautomatika by asi šla, ale je to takové jalové). Asi největší zádrhel vidím v tom, že to není při instalaci systému a výběru řádně vysvětleno a tak nějak mi přijde, že se zmiňují pouze výhody BTRFS.
Za mě osobně by bylo super, kdyby se z Grubu dal obnovit nebo načíst systém přes R-sync. Ale myslím, že už na tom pracují (používám Timeshift a byl tam takový feature request). Já mám třeba teď / a /home na SSD a R-sync "snapy" na datovém velkém HDD (obojí EXT4). Pro potřebu obnovy systému by mi vůbec nevadilo, že by načtení sytému trvalo déle a úplně by to (za mě) zrušilo jakékoliv + BTRFS.
-
Filip JirsákStříbrný podporovatel
což samozřejmě po nějaké době vyústí v praktickou neschopnost HDD něco vůbec načíst.
Fragmentace souborového systému není žádná novinka, řeší se od vzniku souborových systémů. Řešila to každá troch větší databáze. A nikdy to nevedlo k tomu, že by z HDD prakticky nebylo možné číst. Když máte soubor po rotačním disku rozházený, bude čtení pomalejší, ale rozhodně vám to nezastaví OS.Vymazáním snapů se vlastně tyto "subsoubory" staly kompaktním celkem
Nikoli, vymazáním snapshotů na btrfs nedochází k žádnému přesouvání dat – soubory, které byly fragmentované, zůstanou fragmentované i po odmazání snapshotů. -
Je to moje osobní zkušenost, co k tomu víc říct. Ano, OS se nezastavil, jen tak stonásobně zpomalil...
Už nevím jak to technicky funguje, zajímal jsem se o to před rokem, nicméně po výmazu snapů byl systém plně funkční tím, že HDD dokázal systém z disku načíst. Logicky tedy muselo dojít k minimálně částečné defragmentaci. Taky je otázka jak moc se jednotlivé snapy integrují co systému, ale zdálo se, že dost.
-
Filip JirsákStříbrný podporovatel
Problém je, že neoddělujete své vlastní pozorování (to je ta vaše osobní zkušenost) od vaší interpretace toho, co se dělo. Přičemž ta vaše interpretace nemá mnoho společného s realitou.
-
Jak tak sleduji, vy jste evidentně odborník na všechno, takže se vůbec nedivím, že s něčím opět nesouhlasíte. Promiňte nám, ne tak pomazaným jako jste vy, naše trestuhodné interpretace a neznalosti. Vlastně vůbec nechápu, proč se s námi zahazujete...
Ale kdybyste měl náhodou trochu té dobré vůle, mohl byste na git hodit zdrojáky na tu vaši věšteckou kouli, kterou evidentně používáte, prosím. Nebo používáte něco víc old school?
-
Filip JirsákStříbrný podporovatel
cziss: Opět vaše chybná interpretace. To, že rozporuju vaše tvrzení, neznamená, že jsem odborník na všechno.
Věšteckou kouli nemám, ale můžu vám prozradit, jak funguje CoW souborový systém. CoW znamená „copy on write“ a znamená to, že když se mají na disk zapsat nějaká data, nepřepíše se jeho původní umístění, ale zkopíruje se celý blok na nové místo a data se přepíšou tam (FS samozřejmě rovnou zapíše nový blok, nezapisuje to na dvakrát). Takže třeba máte soubor dlouhý 4 bloky a je zapsaných v blocích 1–4. Pak přepíšete něco v bloku 3, takže se nová verze bloku zapíše do bloku třeba 10 (protože bloky 5–9 už jsou obsazené). Takže nová verze souboru je v blocích 1, 2, 10, 4, zatímco původní verze v snapshotu je v blocích 1, 2, 3, 4. Když ten snapshot smažete, blok 3 se označí jako nepoužívaný. Aktuální verze souboru ale stále zůstává v blocích 1, 2, 10, 4. Takže pokud měl HDD problém přečíst data z bloků 1, 2, 10, 4 před smazáním snapshotů, bude mít úplně stejný problém přečíst je ze stejných bloků 1, 2, 10, 4 i po smazání snapshotů.
Všimněte si, že nijak nepopírám vaše tvrzení, že časově po smazání snapshotů jste pozoroval zrychlení práce s diskem. Rozporuju jenom vaše fabulace, co bylo příčinou zrychlení, které neodpovídají realitě toho, co znamená CoW souborový systém.
Howgh.
-
To jste si dost zjednodušil a v případě dvou třech snapů by to tak i bylo... Ale pro začátek - v reálu měníte data jednoho souboru ve více blocích, které nemusí být vedle sebe. To o čem jsem psal já je, že nemáte jeden snapshot, ale máte jich podstatně více, takže máte X subvolumes pro každý soubor, kde jsou bloky dat rozházené po celém disku a samozřejmě některé snapy můžou mít některé identické původní bloky přepsané opět Xkrát. Vymazáním všech snapů na 0, tedy dojde ke "slepení" daných souborů a k minimálně nějaké defragmentaci. Kdyby to tak totiž nebylo, tak když to trochu přeženu, tak byste nakonec skončil s tím, že byste měl na disku každý bajt každého souboru samostatně rozházené po celé vrstvě disku - opět se bavíme o HDD v mém původním případě.
-
Filip JirsákStříbrný podporovatel
To jste si dost zjednodušil a v případě dvou třech snapů by to tak i bylo...
Nikoli, CoW souborový systém takhle doopravdy funguje, a počet snapshotů na tom nic nemění. Snapshot v CoW souborovém systému dělá jedinou věc – normálně by se po zápisu dat do nového bloku ten původní označil za volný a později by se mohl přepsat, snapshot zařídí to, že na ten blok zůstane aktivní odkaz, blok je pořád považován za obsazený, nemůže se použít na nic jiného a je možné z něj kdykoli přečíst ta původní data.v reálu měníte data jednoho souboru ve více blocích, které nemusí být vedle sebe
To je ovšem z hlediska HDD horší případ i bez CoW souborového systému. Jestli jsou bloky rozházené kvůli CoW nebo kvůli přirozené fragmentaci souborů je HDD úplně jedno.Vymazáním všech snapů na 0, tedy dojde ke "slepení" daných souborů
Tak ještě jednou a pomaleji: Zrušením snapshotu se žádné datové bloky na disku nepřesouvají. Zrušením snapshotu se pouze některé dříve používané bloky označí za nepoužívané. Pokud jste měl v aktuálním snapshotu nějaký soubor defragmentovaný a zrušíte předchozí snapshoty, ten soubor zůstane úplně stejně defragmentovaný, s jeho datovými bloky se nijak nehýbe. Ano, je možné, že v úplně původním rozložení bloků souboru vzniknou díry, kam by se daly ty novější bloky přesunout a soubor tak defragmentovat. Ale btrfs to při zrušení snapshotu nedělá.minimálně nějaké defragmentaci
V btrfs k ní nedojde. Zrušení snapshotu je co nejlevnější operace, pouze se označí dané bloky jako volné, ale nic se s nimi neděje a použijí se až při dalších zápisových operacích. A nebo byste musel ručně vynutit defragmentaci.Kdyby to tak totiž nebylo, tak když to trochu přeženu, tak byste nakonec skončil s tím, že byste měl na disku každý bajt každého souboru samostatně rozházené po celé vrstvě disku
Ne, tak byste neskončil. btrfs nepracuje s bajty, ale s bloky pevné velikosti. Když změníte jediný bajt, zkopíruje se celý blok a při zápisu té kopie se ten jeden bajt zapíše upravený. To jsem psal v předchozím komentáři. -
BTRFS používám na mnoha počítačích už mnoho let a asi 3x jsem v rozbitém FS přišel o data, přesto ho preferuji. Jakmile mi totiž FS zahlásí nějakou chybu, následuje důkladná kontrola HW (smartctl, memtest) a světe div se, vždycky tam chyba byla. Nejzáludnější jsou některé poruchy RAM pamětí, PC nemusí přitom padat a mrznout, vše funguje ale protože se nevyužitá paměť používá na disk cache, tak se v ní data zmrší a zapíší se "správně" do FS. BTRFS je první kdo to dík důkladným kontrolám zjistí, ostatní FS (Ext?, NTFS apod.) fungují a vůbec netuší, že mají rozbitá data, ale pokud se to nechà pár týdnů/měs. takhle běžet nevratně se jednou rozbijí také a to bez varování a nic už pak nezachráníte.
-
To je podle mně špatně. Je hezké že to zahlásí chybu hw, ale software by měl být fault tolerantní. Pokud tedy nejde o nějakou vědeckou workstation nebo superpočítač. Očekávat od průměrného uživatele, že si bude levně udržovat hw na 100% je pitomost. Např. já vím o problémových komponentách v mém pc, ale dokud fatálně neselžou tak je provozuju a očekávám, že sw se s tím vypořádá, minimálně do té doby, než provedu kompletní obměnu hw. Ale to se děje vždy po pár letech, do té doby to musí vydržet. Pokud ne, tak je to špatný sw a je lepší se mu vyhnout.
-
Filip JirsákStříbrný podporovatel
Není to špatně. Aby se software mohl vyrovnat s chybami, musí se o chybě nejprve dozvědět. A teda pokud nejdou přečíst data z disku, samozřejmě to probublá až k uživateli – software si ta data obvykle domyslet nemůže.
-
Je hezké že to zahlásí chybu hw, ale software by měl být fault tolerantní.
Do jisté míry.
Očekávat od průměrného uživatele, že si bude levně udržovat hw na 100% je pitomost. Např. já vím o problémových komponentách v mém pc, ale dokud fatálně neselžou tak je provozuju a očekávám, že sw se s tím vypořádá, minimálně do té doby, než provedu kompletní obměnu hw.
K tomu už fault tolerance neslouží. Slouží k tomu poskytnout bezpečí a přiměřený čas na nápravu stavu. Lze tedy akceptovat, že v takovém stavu software funguje omezeně a s nižší výkonem. Tím se obvykle kompenzuje riziko hlubšího poškození, kdyby se závada prohlubovala.
Každopádně provoz na chybujícím hardwaru už nelze považovat za provozní stav. Lze posuzovat, jestli filesystem vydrží nejčastější typy selhání (to lze i porovnat s konkurencí), ale nelze to a priori povýšit na standard.
-
Nejzaludnejsi jsou chyby radicu blokových zařízení.
Pokud nemáte ECC paměti a řádně monitorovany system - jako třeba sledování citacu chyb na cpu a sběrnici, tak se radši do uložení důležitých dat bez nějaké vyšší replikace nad více kusy low cost hw nepoustejte.22. 7. 2020, 15:49 editováno autorem komentáře
-
L.Stříbrný podporovatel
V tom případě doporučuji, přihlaste se BTRFS jako tester, jste evidentně muž nevšedního talentu :)
-
Ano to jsem. Většina dobře fungujících věcích se v mých rukou rozbije. Na druhou stranu, už jsem takhle hlásil horlivě chyby na Apache CouchDB, až mně zablokovali přístup na issue tracker a jejich twitter.
On si z toho Apache udělal tech support a neopochopil, že tam nepíšu proto, že já potřebuju pomoc, ale že já chci pomoci jim. Samozřejmě že za drtivou většinu problému mohla nekompetence. Oni jsou přece dokonalí, chyby v produktu nemají, a nějaký Novák jim nebude říkat, že to je jinak. To nesedí do mediálního obrazu. Samozřejmě většina mnou nahlášených chyb je už opravena (tiše) a ten zbytek tam sice je dál, ale dají se workaroundnout.
-
Filip JirsákStříbrný podporovatel
Jestli jste ty chyby hlásil způsobem: „Všechno kolem mne je špatně, jenom já jsem neomylný; buďte rádi, že někdo jako já se vůbec obtěžuje vám hlásit chybu,“ tak se za ten ban ani nedivím.
-
Filip JirsákStříbrný podporovatel
Vaše smůla je, že není problém si ty tikety dohledat. A zjistit, že je problém opravdu na vaší straně.
-
Možná, že se Fedora plošným nasazením Btrfs zaslouží o vyřešení některých letitých nedostatků tohoto Fs.
Mimo jiné nemožnost efektivního offline checku s opravou chyb. Zadalší mizerná výkonnost s SMR disky. A také příliš velké zatížení procesoru při online checkování (scrub atp.) na slabších strojích. Btrfs už provozuju možná 10 let a zatím vidím téměř nulový pokrok v těchto oblastech, z čehož usuzuji, že ve vývojářském týmu bude nějaká konkrétní žába na prameni (v rozhodovací pozici), která úsilí v těchto věcech zatvrzele blokuje, patrně proto, že to nepovažuje za relevantní... -
> Mimo jiné nemožnost efektivního offline checku s opravou chyb.
Od tohto odstupujú aj ostatné filesystémy. Offline check pri dnešných veľkostiach filesystémov môže trvať dni, a to je na offline príliš dlho. Preto sa snažia prejsť na online opravu chýb.
A v žiadnom prípade preventičný fsck pri každom 20-tom nabootovaní. Viete si predstaviť, že by vám server bootoval týždeň-dva iba kvôli preventičnému fsck?
> Zadalší mizerná výkonnost s SMR disky.
Ktorý fs nemá mizernú výkonnosť so SMR diskami? Žeby to bolo mizernou výkonnosťou SMR diskov samotných?
SMR je použiteľné naximálne pri host-managed SMR, keď máte na to navrhnutú celú architektúru storage. Disk-managed SMR bude vždy problematický z hľadiska výkonu.
> A také příliš velké zatížení procesoru při online checkování (scrub atp.) na slabších strojích
Na atome (C2538) som si ani nevšimol.
-
Preventivní pravidelný offline check je úplný nesmysl, když máte online automatický check, který to řeší na pozadí - tohle jsem neměl na mysli. Ale *** nouzový offline check, který spolehlivě řeší středně těžké problémy *** (např. oblíbený power-off failure death) má IMHO stále smysl a ve většině případů to bude efektivnější než se pak snažit vykopírovat data na jiný harddisk, formátovat a znovu kopírovat. V lokálním případě to bude znamenat tam ten náhradní disk přinést, připojit, nabootovat do jiného systému atd. Na dálku přes admina taky možné, ale rychlost může být ještě podstatně menší. V každém případě opruz na x-hodin, protože to člověk musí sledovat a aktivně něco dělat (i kdyby nakrásně nasadil záložní server). Ze zkušenosti si pamatuju, že kontrola 1TB rotačního disku u ext4 mi i v případě oprav chyb trvala podstatně kratší čas (desítky minut)
SMR disky mají jen v některých případech špatnou výkonnost, existuje možnost jak to aspoň částečně řešit, přičemž nějaká podpora je v kernelu tuším od verze 4.12. Mně se podařilo vytunit fs tak, že aspoň pro archivační účely rychlosti příliš nepadají a jsem zatím celkem spokojen za tu cenu, kdybych ale měl možnost volby, pořídím PMR - ty už ale výrobci kromě nejvyšších uber řad téměř nenabízí. A provozovat na SMR core system, nějakou databázi nebo vývoj by byla v každém případě hloupost, od toho jsou SSD.
Měl jsem brtfs na starším ntb s Core2Duo ULV a žralo mi to pravidelně 50% vytížení jádra, což je IMHO moc. Takže na Atomech to bude asi něco podobného, akorát že když je to v NASu, tak to provoz neomezí, protože většina paketů prochází přes hw čipset. Projevit se to může asi až při streamingu s de/kodóváním, nebo kdyby tam člověk provozoval další aplikace přes SSH tunel, tiskárnu, USB zařízení nebo tak.
-
musim potvrdit, ze SMR disky su uplne v pohode v pripade dlhych sekvencnych Write operacii, teda uplne vhodne ako Archivacne mediu, resp. medium pre taketo sekvencne zapisy. Slapu plne v pohode. Musi to vsak byt Simple disk alebo JBOD. Nie RAID.
V pripade presunu SMR disku do RAIDu, ktory nema na urovni Storage systemu podporu HMSMR je to tragedia, hlavne u SW RAIDu:
- objavuju sa write hole (pretoze mnozstvo operacii caka na cache samotneho disku)
- po vyhuleni I/O v pripade bezneho Random I/O je to cista katastrofa. Asi taka ako pad performance pri QLC SSD.
- mame testy aCo sa tyka BTRFS data scrubbing - musim potvrdit, ze na stredne malych NAS s RAID5 nemam paru o tom, ze scrubbing bezi. A to mi tam frci este Snapshot/Replica a 20+ kontajnerov na Atom server line CPU. Mam slusne velku farmu v praci aj doma, takze pisem z reality.
Btw, viac o uspesnom prepojeni LVM s BTRFS RAIDu a pouzivani v praxi sa dozviete na nezislom fore Synoforum.com. Aktualne rozbiehame uz aj lokanu CZ/SVK verziu.Btw, tie posty zopar jedincov k teme straty dat na BTRFS - zalohy nic? Stracat data si naozaj zasluzi ten, kto sa o ne nestara.
-
Check se porad vyviji. Chyby, co se objevuji, jsou spis zpusobene vadnym hardwarem (nejcasteji memory bitflip, u disku firmware), takze hodne zalezi jestli se z toho da nejak poznat, kde ta chyba zacala a kam az se rozsirila. Ohledne efektivity je ve vyvoji mod, ktery se nesnazi udrzet v pameti vsechna metadata, za cenu, ze neco musi cist znovu z disku.
S drive-managed SMR disky se toho moc udelat neda a mel to byt spis takovy predel nez se upravi software. WDC pracuje na podpore host-managed SMR. Talk o tom treba tady https://osseu19.sched.com/event/TPI0/file-system-support-for-zoned-block-devices-naohiro-aota-damien-le-moal-western-digital .
Na slabsich strojich bude s CPU asi problem obecne, scrub cte data skoro linearne, takze dovede asi saturovat pomalejsi procesor na pocitani checksumu, pripadne pouziva intenzivne pamet a tahle rezie bude znat.
Ohledne konspiraci se zabami na prameni muzu zodpovedne prohlasit, ze blokuju zejmena kod, ktery nesplnuje naroky na kvalitu nebo neimplementuje svuj usecase dostatecne :) Kdyz by nekdo prisel s vylepsenim scrubu tak nebudu proti a pomuzu. S checkem je to tezsi, protoze neni nejaky univerzalni navod, jak co presne udelat, takze se vic diskutuje a premysli.
ČLÁNKY DO MAILU