Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
BTRFS je nejlepsi, pouzivejte BTRFS, proste BTRFS, BTRFS, BTRFS.
BTRFS konci.
Asi tak, tohle je na stejny urovni jako kdyz Canonical mele nekolik let o responsivnim Unity a pak ho zrusi, RedHat zase tak dlouho mlel o nejlepsim souborovem systemu, az ho zrusil.
Posledni dobou konzistence na linuxovych distribucich jak u Microsoftu: Areo, ne Aerou, nabidka Start, nenabidka Start, mobilni dlazdice, nemobilni dlazdice, ....
A Microsoft a jeho ReFS/ne-ReFS přešlapování? S vývojem nových souborových systémů je to poslední dobou těžké obecně.
Nejenom souborovych systemu, vzdycky se do neceho vrhnou, oznami to svetu, jak to bude nejuzasnejsi a za par mesicu zjisti, ze na to nemaji sily a rusi se.
Jaké přešlapování? REFS je FS určený pro zvýšený dostupnosti a ukládání větších objemů dat než NTFS, navíc v kombinaci se storage spaces ochrání před bit rotem. Ve Win 2016 pak o ideální FS pro ukládání Hyper-V - opět pro větší objemy dat.
"navíc v kombinaci se storage spaces ochrání před bit rotem."
Jsem fakt zvědavý, jak vás souborový systém ochrání před http://www.catb.org/jargon/html/B/bit-rot.html ... :-p
No bit rot je běžně chápán jako překlopení 1/0 bez detekce FW disku či OS.
Filesystém v případě ZFS nebo REFS + Storage Spaces si ukládá kontrolní součty a pravidelně provádí scrubing.
Problém běžného mirror raidu je v tom, že i když je nalezena inkonzistence, RAID neví na kterém disku je to správně. Ale např. u Storage Spaces s REFS to díky kontrolnímu součtu zjistit jde, takže může dojít k online opravě.
Třeba CERN na to má docela pěknou studii...
"No bit rot je běžně chápán jako překlopení 1/0 bez detekce FW disku či OS."
V tom případě je ale vaše současné běžné chápání úplně odlišné od dřívějšího běžného chápání.
Fakt celej Crha. Mas to totalne domotany. Ono totiz btrfs neni od RedHatu... ale od Oraclu. A jako u vetsiny veci je s Oraclem tezky porizeni, takze se jejich produktu distribuce radsi zbavej.
Ale no tak, Redmaxi, už nezlob. Přeci ani Canonical ani Red Hat nejsou Linux, ale jeho "dvě distribuce". Jsem si vědom, že český internet je ohledně Linuxu uzavřen především do světa Debianu a jeho forků, ale realita je přeci jiná. BTRFS tlačil Red Hat a SUSE, ale ve zbytku tohoto světa byl regulerně válcován EXT4 (důvody - funkce, stabilita, spolehlivost) a je nasazován v ostatních distrech jako výchozí celou dobu. Unity bylo spíše DE, které mělo "odlehčit a umravnit Gnome 3", ale vydali se cestou ještě méně funkčního prostředí a neřešili skutečné problémy GTK / Gnome (Apps). Podle mého názoru Unity pomohli srazit vaz Minťáci s jejich Cinnamonem, které je jakožto DE použitelnější a začalo obsahovat opravy léta starých chyb ze světa GTK, jako např. změna práv a vlastníka souborů v adresářích a podadresářích (v podardesářích to Nemu ještě taky nejde, ale aspoň se to někam posunulo). Tato chyba je v GTK file manažerech 180 let a jednu zimu. Jako další příklad mne napadá, že zrovna nedávno jsem narazil na archiv, který jsem chtěl rozbalit na laptopu (Cinnamon + File Roller) a nešlo to. Ano byl to archiv od čuníka (zip v raru s brutální diakritikou, vykřičníky apod.), přesto jej stačilo poslat na pracovní stroj (KDE Plasma + Arc) a zde proběhlo rozbalení normálně. Osobně si myslím, že jsou důležitější věci, než Shell nebo neShell, křížek vpravo nebo vlevo či ikony square vs circle. Věřím, že pro ortodoxní GTK uživatele bylo Unity původně osvěžující, ale vlastně neřešilo ze skutečných "GTK problémů" nic.
Ja uz jsem s linuxem skoncil, mam to doma jen na pocitaci, ze ktereho jsem udelal neco jako diskove pole.
Pred casem jsem se k problematice souborovych systemu dostal oklikou pres potrebu zjistit jaky souborovy system na SSD (dal jsem tam nakonec to co jsem daval vzdycky - EXT4). Narazil jsem mimo jine i na BTRFS, kteremu co jsem cetl linuxaci (prave i lide od Redhatu) fanaticky tleskali. Tim ze uz linux ne, tak jsem to dal nesledoval a ted tady ctu ze konec, tak me to rozesmalo. :-)
Ja vim, distribuce a linux (rozumej jadro) jsou neco jineho, ale ja to takto nerozlisuju. Kdyz jsem postupne vyradil vsechny bezne distra kvuli nejakym chybam, tak jsem si proste rekl, ze uz to stacilo. (A samozrejme povinna odbocka pro mistni tucnacke fanatiky - mluvime o desktopu, ma profesionalni draha spravce serveru jiz skoncila, takze tuto relevantni kategorii z meho pohledu logicky pomijim.)
Já jsem neměl na mysli Linux = jádro. Také v obecné mluvě v této tématice myslím operační systém se vším všudy. Stejně jako používáme celou sestavu (HW), tak používáme operační systém. V diskuzích na této úrovni to rozlišovat smysl nemá, ač jsem takové tendence také měl (kernel, DE, apps) . Ale zpátky k věci.
Myslel jsem to tak, že tyto dvě firmy netvoří ani nezastupují tento operační systém. Jsou to dvě distribuce. Ano, přispívají velkým dílem do tohoto světa, ale jejich rozhodnutí co zařadí do své instalačky nijak neovlivňuje ostatní distra. Ty to dělají po svém, zařazují to, co uznají za vhodné. brtfs a Unity jsou toho příkladem. Přesto brtfs narozdíl od Unity nekončí. Více se rozepsal Heron, takže to nemá smysl přepisovat. Jemu brtfs očividně sedl a až bude vhodná chvíle, rád s ním na toto téma hodím řeč (nebojte, mimo diskuzi), abych získal jiný pohled.
Jen mám malou výtku nebo lépe řečeno námět k zamyšlení (neber to jako útok). Není podstatné, jestli se bavíme o brtfs či o něčem jiném, ale nemůžeš z pár článků vyvozovat, že brtfs "linuxáci fanaticky tleskali". Není tomu tak. Většina linuxáků nepublikuje a nepouštějí se do velkých diskuzí na webu. Že vyšel na Rootu nebo jinde článek o brtfs a jsou pod ním názory uživatelů a pár adminů, tak to neznamená, že linuxáci něčemu tleskají. Každá technologie ukáže svoji sílu nebo chyby v nějakém časovém horizontu a rychlé soudy nejsou na místě. Byť je to pro spoustu lidí zábavou a v posledních letech mi přijde, že i koníčkem. Ukažme si to na poměrně čerstvém HW tématu - Ryzen. Po jeho vydání a prvních testech se zde objevil zklamaný komentář od fanouška AMD (nick si napamatuji) ve smyslu "zase ty hry, jdu se vožrat". Dneska, jestli už vystřízlivěl, tak zjistil, že jeho soud byl, no řekněme, unáhlený. Z druhého tábora poskakoval radostí BTJ a dělal na fanoušky AMD dlouhý nos. Obojí je extrém, ale pomůže mi nastínit, co ti chci říct. Pokud se podíváš zpět, nedělal si tak rychle závěry. Nezapomínej, že pár článků = pár lidí = pár názorů. Ve starších diskuzích jsi se od běžného diskutéra odlišoval tím, že jsi byl přístupnější novým informacím a byl si schopný svůj názor přehodnotit. Poslední dobou vynášíš ale soudy příliš rychle a leckdy bez dostatečných informací. Příkladem budiž "herní" Vega, u které víš, že bude mít slabý výkon, aniž by vyšla a byly publikované rozsáhlé testy. Netvrdím, že Vega bude skvělá, už jsem psal v minulosti, že neočekávám stejný úspěch jako u Ryzenu, ale přesto je to otevřené téma a závěr můžu učinit až v září či říjnu, až si všechno "trochu sedne".
"Jemu brtfs očividně sedl a až bude vhodná chvíle, rád s ním na toto téma hodím řeč (nebojte, mimo diskuzi), abych získal jiný pohled."
Jasně, klidně napiš. Uteklo opět hodně času (s btrfs jsem začínal v 2010, na ostro nasadil v 2011), dneska už bych šel zase trochu dál. Koncept btrfs zachovat, ale rozšířit jej na síť. "Připoj disk do libovolného stroje na síti, zvětší se ti dostupné místo všude. Se zachováním redundace i odolnosti proti výpadku jednoho stroje." Hrajeme si s CEPH, ale to pořád není ono. Hlavně z hlediska snadnosti administrace. Časem o tom něco napíšu, až bude více zkušeností z produkce.
Super, díky. Rád poklábosím a dozvím se zkušenosti. Prolezl jsem, co jsi napsal na svůj web, ale stejně budu ještě zvědavý.
Red Hat nikdy nebyl velkým podporovatelem BTRFS, naopak se k němu stavěl hodně vlažně a ani do jeho vývoje mnoho neinvestoval, takže to rozhodnutí je zcela v souladu s jeho předchozím dlouhodobým postupem. Už ti ta nenávist vůči Red Hatu úplně zatemňuje mozek.
nebol Btrfs jednym s tych OS, co ukladali len metadata vo forme diffov, podobne ako git,subversion, Concurent version system a pod.? a teda sa dalo vratit do lubovolnho stavu?
A robil snapshoty len kovli rychlosti, citania?
Snapshoty btrfs nevytváří automaticky, ale na požádání (příkaz btrfs sub snap).
Některé OS, tuším třeba OpenSUSE, používají btrfs jako výchozí FS pro rootfs a vytváření snapshoty při různých akcích (instalace balíčků, update apod.).
Lze si to velmi snadno naskriptovat a vytvářet snapshoty třeba každou hodinu. Není problém.
Ano, s trochou zjednodušení lze říct, že je to takový verzovací systém pro binární data. Díky copy on write principu je pořízení snapshotu velmi levné. Místo se alokuje až časem. Takže pokud uděláte snapshot 1TB souboru (nebo obecně subvolume) a změníte tam třeba jen 1MB, tak je potřeba místa na disku pouze pro tu 1MB změnu (pro kopii bloků) + nějaká nutná metadata.
Takových snapshotů můžete mít kolik chcete (až do velikosti volného místa na disku pro ty změny). A potom můžete kterýkoliv snapshot smazat a uvolnit tak místo na disku, které zabírali jeho změny.
Je to velmi pohodlné, před každou "potenciálně nebezpečnou" (tedy pokaždé, protože to nic nestojí) akcí nad daty si udělám snapshot a potom se můžu vrhnout do úprav těch dat. Třeba změnit v 300GB souborů jejich hlavičky. Pokud se mi to nepovede, tak prostě obnovím ten snapshot.
Takze taky medzikrok. Ja som uvazoval o FS, kde nie su data, ale len metadata - t.j.zapisy o zmenach na disku a ovladac by z nich v RAM rekonstruoval data..
Takže něco jako ten FS, kde se místo dat ukládal offset v čísle π
Je zaujímavé že Synology do svojich NAS Btrfs len nedávno pridal a vyzdvihuje vyššiu odolnosť proti chybám a zálohovanie. Na vyšší výkon však odporúča ext4.
https://www.synology.com/cs-cz/dsm/Btrfs
Nevím, co s tím dělá Synology, ale já Btrfs používám na zálohování na externí disky a kombinace kontrolních součtů na souborech se snapshoty je skvělá. Mít 30 a víc denních záloh např. 2T úložiště na 3T disku s tím, že ještě 1/2T zbývá jako rezerva pro změny je luxus.
(Samozřejmě je dobré zálohovat duplicitně a třeba i na jiný filesystém, ale za posledních pár let se mi to chovalo velmi stabilně, tak snad to tak zůstane.)
Vím, že tam je dost nedokončených věcí, myslím že RAID 5 na úrovni filesystému, ale to mě nijak netrápí. Experimentoval jsem s mirrorem a spojováním disků do jednoho FS, to fungovalo obstojně i když to nasazené nemám.
"Je to celkem logické, Btrfs se nikdy/zatím nepodařilo dotáhnout funkcionalitou do řekněme téměř 100% stavu, přičemž jiné souborové systémy jsou buď léty prověřené a nadále inovované (jako Ext4), nebo prodělávají výraznější vývoj (jako XFS, na kterém v Red Hatu pracuje mimo jiné spousta hodně schopných lidí, kteří do firmy přišly od Hanse Reisera)."
Tohle srovnání dost pokulhává, protože jak ext4, tak xfs nenabízí funkce, co má btrfs. Pokud se btrfs používá stejně jako staré systémy souborů, tak prostě funguje.
Plus btrfs je právě v těch dalších vlastnostech vycházející z COW. Snapshoty, subvolumes, send receive. Dále je to fakt, že btrfs je multidevice a přinesl podporu, jako zatím nikdo jiný (přidejte disk / odeberte disk kdy chcete a nezajímejte se o typ raidu. Prostě do raid1 dejte 5 disků a ono to pojede. Potom dva odeberte (pokud je dostatek místa) a ono to stále pojede. Tohle je pro mě killer vlastnost btrfs.)
Jestli něco btrfs "chybí", tak to je dokončení vývoje ekvivalentu raid5/6.
Jinak, celé to na mě trochu dělá dojem NIH syndromu. RH pracuje velmi intenzivně na XFS, je to jeho výchozí systém a podařilo se jim ho velmi brutálně zrychlit. Přidali tam i kontrolu checksumů, zatím jen metadat (btrfs má kontrolu všech datových bloků). Plánuje se přidání podpory snapshotů i do XFS, ale zatím na stole nic není (a tohle není záležitost chvíle, to si ještě hezkých pár let počkáme).
Takže, BTRFS nekončí, to, že to nemá RH nic neznamená (afaik měli jen jednoho btrfs vývojáře, který odešel). BTRFS pokračuje dál, ve FB je intenzivně vyvíjen a nasazen.
Víte někdo, jaká funkcionalita v btrfs není dotažená na 100% ?
Já vím jen o raid5/6. Ale to bych nepovažoval za show stopper.
https://btrfs.wiki.kernel.org/index.php/Status
(kvoli odpovedi som sa musel registrovat :/ )
On viacmenej celý BTRFS nie je dotiahnutý do konca. Je to kopa dobrých nápadov, na ktoré sa niekto v polovici implementácie vykašľal - https://btrfs.wiki.kernel.org/index.php/Gotchas
Ja som sa v práci do BTRFS pred rokom vrhol plnou parou a po 6 mesiacoch sme museli všetko migrovať na ZFS a Ceph. BTRFS má niekoľko vylepšení v porovnaní so ZFS, ale implementácia je naprd. Pre mňa to skočilo na tom, že jednoducho nezvláda veľké množstvo snapshotov (klonov).
ZFS má všechno výše uvedené a více. Na jeho vývoji se podílelo daleko víc lidí, hlavně ještě když to měl Sun a bylo to open source. V čem je BTFRS lepší?
Já jsem o ZFS nic nepsal. ZFS a BTRFS pocházejí především z dost jiných prostředí.
Pro mě osobně je BTRFS mnohem víc flexibilnější. Do ZFS nelze jen tak bez následků přidat disk. Do zpool se přidávají pouze vdevy. Všechny vdevy v zpoolu tvoří raid0. Tedy pokud ke 30 diskům v vdevech s nějakou redundancí (mirror, raid-z), přidáte další disk (vdev single) a tento umře, tak jste přišel o vše. Musí se tedy přidávat třeba po dvojicích, jako vdev typu mirror.
Už ty disky ale nikdy neodeberete. Vdevy nelze ze zpoolu odebrat. Pouze přidávat. Ze single vdevu lze udělat mirror (a naopak). Přidat další disky do raid-z nelze. Lze je jen postupně vyměnit třeba za větší.
V btrfs můžu kdykoliv cokoliv přidat a odebrat (pokud je místo na data).
Dále snapshoty a subvolumes. V Btrfs je každý snapshot vlastně další subvolume. Zcela nezávislý. Můžu udělat snapshot subvolume, snapshot si nechat a původní subvolume smazat.
Tohle v ZFS bohužel nejde. snapshot je svázán s původním datasetem. Když chcete udělat clon daného datasetu, uděláte jeho snapshot (ok), tento snapshot naklonujete na nový dataset. Ale ten není nezávislý. Nelze smazat původní dataset ani ten snapshot. Takže místo clonů datasetů raději dělám "hard copy" přes zfs send / receive (třeba při vytváření jailů). Chci mít možnost ten původní dataset smazat.
Tzn. u ZFS se musí mnohem víc přemýšlet hodně dopředu. Jak tam narvete disky? (Pro mě je ideální prostě přidávat vdev mirrory, přidávat po dvou diskách.) Jak budete pracovat s datasety? Jak budete využívat snapshoty?
Tohle je z mého pohledu u BTRFS mnohem flexibilnější. Můžu začít s btrfs nad jedním diskem, potom se rozhodnu přidat druhý a převést to na mirror. Potom zjistím, že mi dochází místo, přidám jeden větší disk a některý z těch původních třeba odeberu. Nic z toho nemusím řešit na počátku.
Subvolume a snapshoty totéž. Jsou zcela nezávislé a mohu kdykoliv kterýkoliv smazat.
Je ale jedna věc, pro kterou ZFS používám a to jsou ZVOLy. ZFS umí z poolu exportovat blokové zařízení, to zařízení může být i sparse (thin). BTRFS umí jen soubory. Ano, lze mít soubor exportovaný jako blokové zařízení (třeba iSCSI), funguje to. Ale exportovat rovnou blokové zařízení je lepší.
Vůbec netvrdím, že jeden FS je lepší nebo horší. Oba mají dobré vlastnosti a je dobré o nich vědět. A třeba oba používat vedle sebe.
Jinak teda ZFS má potíž s licencí. Nekompatibilní s GPL, sice se to nějak různě obchází, ale tvůrci GPL (RMS) se to příliš nelíbí, tak proč to dělat.
> tvůrci GPL (RMS) se to příliš nelíbí, tak proč to dělat
Heh... nemyslim, ze moc lidi z firemniho prostredi zajima osobni nazor RMS, kdyz se rozhoduje o nasazeni toho nebo onoho. Problem je spis to, ze nekompatibilni licence (s "obchazenim") by mohly firmu dostat do prusvihu. Proto ze to resi, ne proto ze RMS se neco nelibi...
Nepsal, já jsem jen zvědavý co je na BTRFS zajímavého, takže díky za srovnání.
Osobně používám ZFS právě přes ty mirrory, zatím tedy po dvou, což jsem dělal i před ZFS kvůli nespolehlivosti velkých disků. Odebírat neplánuju, maximálně fyzicky když mi odejde disk a pak ho vyměním. Na moje domácí ukládání dat to vyhovuje.
Nevím, jestli to je NIH syndrom. Co jsem se bavil se storage vývojáři Red Hatu, tak prostě považují za lepší použít léty prověřený, rychlý a robustní FS (který mimochodem nepochází od nich, takže je těžko lze obviňovat z NIH chování) a funkcionality BTRFS/ZFS dosáhnout vrstvením několika technologií na sebe než mít všechno v FS. Která z těchto cest je lepší, popravdě já nedokážu posoudit.
No... zrovna tohle mi přijde úsměvný. Byť za to ti konkrétní vývojáři asi nemůžou, ale když někdo z RedHatu tvrdí, že je lepší mít několik technologií na sebe než všechno v FS, dost mi to připomíná filozofii Unixu - mít mnoho utilit, kdy každá dělá jen to svoje a dost dobře. Super - ale pak nám z dílen RedHatu přijde systemd, který to všechno boří... (Tím nechci srovnávat dva odlišné světy - init a FS. Jen mě to praštilo celkem do očí...)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.