Vlákno názorů k článku Fedora 33 přejde na Btrfs od cziss - Když jsem před rokem a něco zkoušel OpenSuse,...
-
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ý podporovatelcož 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.
ČLÁNKY DO MAILU