abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
dnes 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
dnes 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 7
včera 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 0
včera 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 6
včera 19:22 | Pozvánky

Již příští týden - 26. a 27. října se v Praze v hotelu Olšanka odehraje OpenWRT Summit. Na webu konference naleznete program a možnost zakoupení lístků - ty stojí 55 dolarů. Čtvrtek bude přednáškový a v pátek se budou odehrávat převážně workshopy a meetingy.

Miška | Komentářů: 0
včera 13:44 | Nová verze

Bylo vydáno Ubuntu 17.10 s kódovým názvem Artful Aardvark. Ke stažení jsou Ubuntu Desktop a Server, Ubuntu Cloud Images, Ubuntu Netboot, Kubuntu, Lubuntu a Lubuntu Alternate, Lubuntu Next, Ubuntu Budgie, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio a Xubuntu. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 22
včera 13:00 | Komunita

MojeFedora.cz informuje, že Fedora 27 dostane podporu pro AAC. Podpora multimediálních formátů je ve výchozí instalaci Fedory tradičně limitovaná kvůli softwarovým patentům, ale desktopový tým Red Hatu se ji i tak snaží v poslední době co nejvíce rozšířit. Už nějaký čas obsahuje kodeky pro MP3, H.264, AC3 a nyní byl přidán také kodek pro další velmi rozšířený zvukový formát – AAC.

Ladislav Hagara | Komentářů: 2
18.10. 23:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. brněnský sraz, který proběhne v pátek 20. října od 18:00 hodin v restauraci Time Out na adrese Novoměstská 2 v Řečkovicích. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
18.10. 21:44 | Nová verze

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 2
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (1%)
 (1%)
 (1%)
 (74%)
 (13%)
Celkem 120 hlasů
 Komentářů: 7, poslední včera 23:06
    Rozcestník
    Zelený chameleon

    Různé drobnosti a užitečnosti na které narazím nebo sám vytvořím. Primárně se zaměřuji na věci, které mohou být zajímavé a užitečné pro ostatní uživatele GNU/Linuxu či typografického systému TeX, občas se tu ale určitě vyskytne i něco z úplně jiného soudku, např. z oblasti bezpečnosti apod.

    Aktuální zápisy

    Btrfs vs ZFS – srovnání pro a proti

    29.2.2016 01:05 | Přečteno: 4785× | Btrfs | Výběrový blog | poslední úprava: 18.5.2016 10:16

    Jsem fanda Btrfs, ale zajímá mne i jeho hlavní soupeř – ZFS. Nedávno se objevily zprávičky o přípravě toho, aby bylo ZFS (i přes problematické licencování) snadno použitelné v Ubuntu a Debianu. To mne přivedlo na (skvělý!) tutoriál Aarona Toponce o ZFS na Linuxu. Na základě něho a ještě několika dalších zdrojů se mi zdá, že Btrfs je v mnoha ohledech navrženo flexibilněji a vhodněji, i když samozřejmě má i své nevýhody. V tomto zápisku tedy zkusím stručně shrnout pro a proti, která u Btrfs a ZFS vidím.

    Upozorňuji, že dost možná budu zápisek čas od času aktualizovat, takže se text může v průběhu času mírně měnit.

    Aktualizace

    Obsah

    Použité zdroje

    Na začátek bych chtěl sepsat hlavní zdroje, ze kterých jsem čerpal, a které by mohly být zajímavé pro zájemce o Btrfs a ZFS.

    Btrfs

    ZFS

    Btrfs a ZFS

    Srovnání Btrfs a ZFS

    Licencování – vítězí Btrfs

    V oblasti licencování je myslím situace poměrně jednoznačná – GNU GPL kód Btrfs je mnohem příjemnější, než CDDL kód ZFS. Canonical tvrdí, že kernelový modul zfs.ko není problém distribuovat v Ubuntu v binární podobě, ale spousta lidí je jiného názoru a Debian nabídne jen zdrojáky, i když tedy nachystané tak, aby je bylo možné snadno zkompilovat a ZFS použít.

    Na druhou stranu je otázka, jestli i GNU GPL nemůže být problém pro portaci Btrfs na jiný systém (BSD nebo podobná licence by byla šířeji přijatelná). Vzato kolem a kolem – z licenčního hlediska pro mne vítězí Btrfs, který je bezproblémový minimálně na Linuxu. ZFS je sice už portované na více systémech, ale licence je IMHO s otazníkem všude a člověk by si tedy měl velmi rozmyslet, jestli na ZFS založí svůj produkt, protože pak může mít velké problémy s tím, jestli ho takto bude moci distribuovat.

    Flexibilita zmenšování úložiště – vítězí Btrfs

    Co mne asi na ZFS zatím zklamalo nejvíce, to je malá flexibilita práce s úložištěm. U Btrfs není problém úplně volně přidávat a odebírat disky do úložiště (za plného provozu). U ZFS je možné disky přidávat a nahrazovat starší disky za nové (větší nebo stejně velké), ale není možné z úložiště zařízení odebrat! Jsou tam nějaké drobné výjimky u zrcadlených zařízení, ale s flexibilitou Btrfs se to vůbec nedá srovnávat.

    Z mého pohledu to tedy vyžaduje hodně dobré plánování, jak bude úložiště i do budoucna vypadat. Pokud se jednou rozhodnete, že budete mít v úložišti šest disků, tak není problém později přidat další disky. Pokud se ale naopak stane, že vám jeden disk odejde a vy nebudete mít po ruce náhradní, tak u ZFS máte problém, pokud se nejedná o jeden z těch pár speciálních případů. U Btrfs byste disk jednoduše z úložiště odebrali a dál používali disků pět (samozřejmě za předpokladu, že na zbývajících discích máte dost místa pro všechna data a konfigurace úložiště [typ RAIDu] může fungovat s daným počtem disků).

    V OpenZFS projektu se před časem objevil zápisek o implementaci odebírání zařízení v ZFS, ale nevím o tom, že by to bylo někde prakticky dostupné. V zápisku uvedený plán zařazení do mainstreamu se asi nerealizoval.

    Jeden z inženýrů, který u Sunu několik let pracoval na ZFS, obecně označuje návrh Btrfs za vhodnější pro úložiště, než design ZFS, který vznikl dříve a vycházel z analogie správy virtuální paměti.

    Odolnost proti výpadkům (více) disků – vítězí ZFS

    V předchozím bodu jsem kritizoval problémy se zmenšením ZFS úložiště, ale při zvětšování už není situace tak jednoznačná.

    Pokud budete mít úložiště, které ze startovních např. 4 disků postupem času naroste na třeba 24 disků, tak u Btrfs jste z hlediska spolehlivosti limitováni dostupnými RAID konfiguracemi. Krom RAID1/5/10, který přežije výpadek jednoho disku, máte k dispozici jen RAID6, který přežije výpadek dvou disků (RAID5 a 6 je navíc v Btrfs stále relativně experimentální). Cokoliv jiného přímo z Btrfs nyní nemáte šanci dostat. U 24 disků už je docela nepříjemné spoléhat na to, že při výpadku jednoho disku už vám další disk neselže, než stačíte redundanci všech dat obnovit.

    U ZFS by pravděpodobně růst probíhal jinak. Iniciální 4 disky by tvořily např. jedno VDEV v nějaké RAID konfiguraci. Další disky by se do ZFS poolu přidaly tak, že by se např. z dalších šesti disků udělalo další VDEV v RAID konfiguraci a přidalo do poolu, kdy by pak ZFS provádělo stripping přes původní a nové VDEV zařízení. Další růst by probíhal obdobně. Oproti Btrfs ale musíte u ZFS dávat pozor na použití stejně velkých disků, jinak nevyužijete jejich plnou kapacitu. Btrfs je v tomto mnohem gumovější.

    Z toho plyne, že v případě ZFS je redundance zajištěna přes každé VDEV, výpadek jedno disku v prvním VDEV neomezí vůbec redundanci ve druhém VDEV. Selhané disky se nekumulují přes celé úložiště. Navíc ZFS poskytuje krom obdoby RAID5 (RAIDZ1) a RAID6 (RAIDZ2) i RAIDZ3, který toleruje výpadek 3 disků. Případně můžete dělat zrcadlené VDEV z libovolného počtu disků (tj. počtu kopií), které uznáte za vhodné.

    Výše uvedené Btrfs neumí, tam si vyberete RAID konfiguraci, která platí pro všechny disky v celém poolu. Dělat tedy pool z hodně zařízení asi není v Btrfs zase tak moc dobrý nápad. Řešení by mohlo být, pokud by Btrfs umožňoval definovat např. RAID1/10 s tím, že se nebudou ukládat jen dvě kopie dat na dvou zařízeních, ale tři nebo více kopií na třech nebo více zařízeních. (Něco podobného ostatně ZFS umí v podobě ZFS Ditto Blocks. Mimochodem, Btrfs nedávno zpřístupnilo možnost režimu DUP pro data, tj. pokud máte Btrfs na jediném disku, můžete nejen pro metadata, ale i pro data nařídit ukládání dvou kopií. Pokud se tedy na disku objeví vadný sektor, tak s trochou štěstí přečtete dobrá data z jiného místa disku, i když nemáte přímo RAID.)

    Na druhou stranu musíte v ZFS pečlivě zvažovat, jestli do poolu další zařízení přidáte, protože pokud to jednou uděláte, tak už je z poolu nedostanete a už napořád budete muset mít pool tvořený tolika zařízeními, i když byste třeba koupili několik málo disků, které by kapacitně převýšili daleko větší počet disků stávajících.

    Výše uvedené chování ZFS by se asi dalo do jisté míry simulovat na Btrfs použitím např. Linux software RAID zařízení místo disků samotných, ale tím (v závislosti na konfiguraci) můžete přijít o schopnost Btrfs samoléčení filesystému – Btrfs nebude mít přehled o redundantních datech zajištěných níže ležící vrstvou (a nebude pro ně mít samostatně napočítané kontrolní součty), takže je nebude moci použít k automatické opravě zjištěných chyb. (Tohle je příklad toho, proč nechcete mít RAID/LVM/filesystém jako tři oddělené vrstvy, které o sobě nic neví...)

    Další zvýšení bezpečnosti dat poskytuje ZFS Intent Log, který se dá využít k tomu, aby se minimalizovala pravděpodobnost ztráty dat mezi commity na disk (nyní se v ZFS v defaultním nastavení dělá tuším po pěti sekundách a uvažuje se o změně defaultu na 10 sekund) při výpadku napájení.

    Flexibilita nastavení RAID konfigurace – vítězí Btrfs

    ZFS je sice možné nakonfigurovat pro větší odolnost proti výpadkům disků, na druhou stranu je jednou provedené rozhodnutí „napořád“. Pokud se rozhodnete, že VDEV bude RAIDZ2, už z něj jiný typ RAID konfigurace neuděláte (a ani ho z poolu neodstraníte :-/).

    Btrfs je v tomto mnohem flexibilnější, mezi RAID konfiguracemi je možné za plného provozu úložiště volně přecházet. Máte nyní úložiště v RAID1 konfiguraci a dochází vám místo?

    btrfs balance start -dconvert=raid5 -mconvert=raid5 /mnt/btrfs-pool/

    Chvíli počkáte a máte více volného místa při zachování odolnosti proti výpadku jednoho disku, protože RAID5 to řeší paritou a nesežere vám celou polovinu kapacity jako RAID1. Potřebujete větší odolnost?

    btrfs balance start -dconvert=raid6 -mconvert=raid6 /mnt/btrfs-pool/

    Chvíli počkáte a máte RAID6 odolný proti výpadku dvou disků.

    Rychlé kopírování/přesouvání dat přes CoW – vítězí Btrfs

    Pod Linuxem můžete copy-on-write vlastností Btrfs (CoW používá i ZFS) využít k rychlému kopírování a přesouvání dat na Btrfs filesystému:

    cp --reflink=auto /cesta/ke/zdroji /cesta/k/cíli

    Program cp se pak místo kopírování dat pokusí jen vyrobit kopii inode, ale samotná data odkáže na bloky původního souboru (neztrácí se tedy čas ani místo na disku jejich duplikací). Na rozdíl od hardlinku se ale původní a nový soubor opravdu chovají jako dva nezávislé soubory, protože při změně kteréhokoliv z nich nejsou data druhého souboru přepsána, ale změněné bloky zapsány na jiné místo na disku a odkázány, což je stejně způsob, jak by Btrfs při přepisu souboru postupoval tak jako tak, protože na copy-on-write je Btrfs založený.

    Obdobný parametr --reflink má i program mv. Jen musíte mít dostatečně novou verzi coreutils.

    Přehled o stavu úložiště a možnosti ladění jeho konfigurace – vítězí ZFS

    ZFS asi poskytuje jasnější a rychlejší přehled o tom, jaký je nyní stav úložiště a jaké akce je případně třeba provést. Včetně např. see sekce s odkazy do průběžně aktualizované knowledge base na webu.

    # zpool status tank
      pool: tank
     state: ONLINE
    status: One or more devices is currently being resilvered.  The pool will
            continue to function, possibly in a degraded state.
    action: Wait for the resilver to complete.
     scrub: resilver in progress for 0h2m, 16.43% done, 0h13m to go
    config:
    
            NAME          STATE       READ WRITE CKSUM
            tank          DEGRADED       0     0     0
              mirror-0    DEGRADED       0     0     0
                replacing DEGRADED       0     0     0
                sde       ONLINE         0     0     0
                sdf       ONLINE         0     0     0
              mirror-1    ONLINE         0     0     0
                sdg       ONLINE         0     0     0
                sdh       ONLINE         0     0     0
              mirror-2    ONLINE         0     0     0
                sdi       ONLINE         0     0     0
                sdj       ONLINE         0     0     0
    

    U Btrfs spíše koukáte přes dmesg do ring bufferu jádra, což není zdaleka tak příjemné, přehledné a můžete případně něco minout.

    Ladění různých vlastností a konfigurace úložiště jsou také o něco podrobnější u ZFS než už Btrfs.

    # zpool get all tank
    NAME  PROPERTY       VALUE       SOURCE
    tank  size           208G        -
    tank  capacity       15%         -
    tank  altroot        -           default
    tank  health         ONLINE      -
    tank  guid           1695112377970346970  default
    tank  version        28          default
    tank  bootfs         -           default
    tank  delegation     on          default
    tank  autoreplace    off         default
    tank  cachefile      -           default
    tank  failmode       wait        default
    tank  listsnapshots  off         default
    tank  autoexpand     off         default
    tank  dedupditto     0           default
    tank  dedupratio     1.00x       -
    tank  free           176G        -
    tank  allocated      32.2G       -
    tank  readonly       off         -
    tank  ashift         0           default
    tank  comment        -           default
    tank  expandsize     0           -
    

    Z read-only proměnných na datasetech můžete mimo jiné získat informace o obsazeném místě na datasetu, jeho potomcích, snapshotech apod. Získání přesných informací o obsazeném a volném místě na Btrfs je dlouhodobě problematické.

    Nastavení proměnných na datasetech se kaskádově dědí. Pokud tedy nastavíte např. algoritmus komprese na kořenovém datasetu, vnořené datasety jej zdědí. Kompresní algoritmus však můžete pro každý dataset ručně změnit (přepsat zděděnou hodnotu) nastavením příslušné proměnné na konkrétním datasetu.

    Btrfs vlastnosti implementuje také. Zatím jich je ale prakticky používáno jen několik málo, navíc spousta věcí se stejně dá nastavit jen globálně pro celý filesystém, nikoliv per subvolume. Obecný mechanismus tu však je, oproti ZFS navíc rozlišuje vlastnosti samostatně pro subvolume, filesystem, inode a zařízení.

    Výkon – vítězí ?ZFS?

    Jak Btrfs, tak ZFS je projektované zejména na spolehlivé uložení velkého množství dat, výkon není priorita. A popravdě řečeno výkon Btrfs ani ZFS nebývá úplně oslňující. Nemám žádný vlastní benchmark ani jsem se nesnažil zjišťovat, jestli lepší výkon poskytuje Btrfs nebo ZFS.

    U ZFS mne ale zaujal koncept Adjustable Replacement Cache (ARC), včetně možnosti přidání rychlých zařízení (dobrého rychlého SSD apod.) jako druhé úrovně ARC mimo RAM. Tohle myslím dává daleko lepší potenciál pro ladění výkonu, než co poskytuje Btrfs.

    Pokud se používá ZFS Intent Log (což se dá použít pro další zvýšení bezpečnosti uložení dat), dá se výkon ladit také jeho umístěním na samostatné rychlé disky.

    Práce se snapshoty a subvolumes – vítězí Btrfs

    Práce se snapshoty je pro mne asi druhé největší zklamání ze ZFS. Způsob fungování Btrfs mi přijde jednodušší a přitom minimálně stejně flexibilní.

    V Btrfs vypadá snapshot úplně identicky jako subvolume (vlastně mi není úplně jasné, proč je to vůbec na uživatelskou úroveň vytaženo jako dva rozdílné pojmy; chápu, že implementačně tam asi rozdíly budou, ale uživateli by to myslím mohlo být jedno a je to dost možná dáno jen historickým vývojem obslužné utility btrfs). Po vytvoření read-only nebo read-write snapshotu ze subvolume je tento na původním subvolume nezávislý (minimálně tedy z uživatelského hlediska).

    V ZFS toto ale neplatí. Pokud vytvoříte snapshot, nemůžete dataset smazat, dokud nesmažete všechny snapshoty. Navíc je snapshot tak nějak napůl skrytý. V Btrfs je snapshot vlastně další podadresář (nebo možná spíše mountpoint) někde v adresářové struktuře. V ZFS běžně vidět není. Nebo vlastně tak napůl: existuje skrytý adresář .zfs, který je ale ve výchozí konfiguraci ZFS skrytý více, než by člověk čekal, nevypíše ho ani utilita ls, i když se do adresáře dá vstoupit:

    # ls -a /tank/test
    ./  ../  boot.tar  text.tar  text.tar.2
    # cd /tank/test/.zfs/
    # ls -a
    ./  ../  shares/  snapshot/
    # zfs set snapdir=visible tank/test
    # ls -a /tank/test
    ./  ../  boot.tar  text.tar  text.tar.2  .zfs/
    

    Přes obsah .zfs se tedy asi člověk k jednotlivým souborům dostane, aniž by musel provést vyloženě rollback datasetu k danému snapshotu (což mimochodem znamená smazat případné všechny mezilehlé snapshoty!).

    Způsobu práce Btrfs se v ZFS více podobá použití operace klonování datasetu, což se dá udělat i z libovolného snapshotu, opět tam ale je závislost, takže není možné zdrojový snapshot smazat, než se smaže z něj vytvořený klon. Respektive se to asi dá obejít použitím operace promote.

    Co naopak považuji za velké plus ZFS (a dost chybí v Btrfs) je rekurzivní režim tvorby/mazání snapshotů. Pokud potřebujete vytvořit snapshot datasetu, kde jsou níže ležící další datasety, tak to ZFS obslužná utilita zvládne sama jediným příkazem. Rychle jsem nenašel, jestli to funguje i pro klonování datasetů, doufal bych, že ano. Rekurzivní režim je totiž dostupný i pro ZFS send/receive (kde pro Btrfs send/receive opět chybí), takže u ZFS se na to asi obecně myslelo.

    Integrované šifrování – vítězí ?ZFS?

    Zajímavou funkcí moderního filesystému může být integrované šifrování. U Btrfs je šifrování plánováno, ovšem zatím se na něm asi vůbec pracovat nezačalo a zbývají tak jiné nástroje, na které je člověk stejně odkázán u většiny linuxových filesystémů, protože integrovaná podpora šifrování u nich prakticky neexistuje.

    ZFS je na tom lépe, tam je šifrování implementováno. Ovšem záleží na verzi. Vývoj ZFS se začíná štěpit a je třeba rozlišovat Oracle ZFS na Solarisu a open-source OpenZFS, které se typicky používá jinde. Šifrování je dostupné od ZFS pool revision 30 v Oracle implementaci. Pokud jsem ale správně vyrozuměl, tak OpenZFS se oddělilo zhruba na pool revision 28 (dále je to složitější, protože OpenZFS zavádí feature flags a pool revision vystřelil na 5000, aby nedocházelo ke konfliktům s původním číslováním, které Oracle dále používá) a podpora šifrování v něm není.

    Osobně bych se divil, pokud by k přenosu této implementace do OpenZFS došlo (vzhledem k „povaze“ Oracle a faktu, že v ZFS má hromadu peněz a považuje jej za součást svého firemního business). Spíš bych očekával, že pokud se šifrování v OpenZFS objeví, tak to bude jiná implementace než ta od Oracle. Třeba se ale pletu a budu mile překvapen.

    ZFS tedy v oblasti šifrování vítězí, pokud se bavíme o použití Oracle Solarisu, kdekoliv jinde je na tom prakticky stejně jako Btrfs – šifrování integrované není.

    Defragmenatace – vítězí Btrfs

    Jak Btrfs, tak ZFS jsou copy-on-write filesystémy, takže fragmentace dat při jejich průběžné změně je problém. Jak Btrfs, tak ZFS se tomu snaží různými technikami bránit. U ZFS ale neexistuje příkaz pro defragmentaci (pokud vím, tak se jako workaround používá zkopírování dat), u Btrfs je k dispozici on-line defragmentace pomocí btrfs filesystem defragment. Dá se přitom pustit na vybraných souborech, nebo rekurzivně na celém vybraném podstromu filesystému.

    Na Btrfs je navíc v případě potřeby možné aplikovat nodatacow mount volbu (platná pro celý filesystém), respektive nastavit rozšířený atribut C na vybraném souboru/adresáři (musí být nastaveno, dokud je ještě soubor/adresář prázdný): chattr +C /cesta/k/souboru To pak způsobí vypnutí copy-on-write pro daná data (což může znamenat velký výkonností přínos pro specifické typy zátěže, např. datové soubory databázových serverů, jde je mnoho náhodných zápisů do velkých souborů), ale na druhou stranu znamená i automatické vypnutí počítání checksumů na těchto datech, vypnutí komprese a zvýšení pravděpodobnosti nekonzistentních dat na disku při výpadku napájení apod., takže je potřeba velmi dobře zvážit, jestli nám to opravdu stojí za riziko.

    Export blokových zařízení (ZFS Volumes) – vítězí ZFS

    Export blokových zařízená je velmi zajímavá vlastnost, kde ZFS vítězí jednoduše proto, že v Btrfs žádná obdoba této funkce neexistuje.

    Přiznám se, že o ZFS Volumes jsem neměl tušení, než jsem na to teď narazil v tutoriálu Aarona Toponce. Přitom je to velice zajímavá funkce, která umožňuje v systému vytvořit plnohodnotné blokové zařízení v /dev, do něhož zapsaná data jsou uložena v ZFS filesystému.

    Při vytváření ZVOL je třeba specifikovat jeho pevnou velikost, ale vytvoření je prakticky okamžité i pro velmi velké kapacity. Předpokládám, že ve skutečnosti není na filesystému žádné místo alokováno a udat velikost je nutné jen kvůli tomu, aby ZFS věděl, jakou velikost u vytvořeného blokového zařízení uživatelům hlásit.

    # zfs create -V 1G tank/disk1
    # ls -l /dev/zvol/tank/disk1
    lrwxrwxrwx 1 root root 11 Dec 20 22:10 /dev/zvol/tank/disk1 -> ../../zd144
    # ls -l /dev/tank/disk1
    lrwxrwxrwx 1 root root 8 Dec 20 22:10 /dev/tank/disk1 -> ../zd144
    

    Je to tedy obdoba vytvoření souboru ve filesystému, který pak navážete na nějaké /dev/loopx zařízení přes losetup.

    ZFS volumes jsou tedy zajímavá možnost např. pro vytvoření úložiště pro virtuální stroje – místo ukládání dat do image souborů spravovaných hypervizorem může hypervizor použít ZVOL blokové zařízení, ZVOL můžete využít pro uložení swapu na ZFS apod. Přitom i pro ZFS volumes máte k dispozici kontrolu integrity, snapshotování, deduplikaci, kompresi, redundantní uložení a další vlastnosti, které ZFS na daném poolu poskytuje.

    „Integrované“ sdílení přes NFS/Sambu/iSCSI – vítězí ?ZFS?

    V ZFS se dá mnoho věcí konfigurovat nastavením příslušných proměnných na poolu/datasetech. Mimo jiné se dá nastavením proměnné na datasetu zapnout jeho sdílení přes NFS/Sambu/iSCSI. Např. pro NFS to může vypadat takto:

    # zfs set sharenfs="rw=@10.80.86.0/24" pool/srv
    # zfs share pool/srv
    # showmount -e hostname.example.com
    Export list for hostname.example.com:
    /srv 10.80.86.0/24
    

    Do nadpisu jsem dal vítězství ZFS s otazníkem. Nejsem si totiž úplně jistý, jestli je tohle vlastnost, kterou u ZFS oceňuji, nebo je to prostě jen další položka na seznamu funkcí, které má, takže si za ni uděláme čárku.

    Osobně bych sdílení dat přes NFS/Sambu/iSCSI nechal čistě na konfiguraci daných serverů. Ty totiž stejně musí běžet, přímo ZFS kód neobsahuje implementaci NFS/Samba/iSCSI serveru – proto ty uvozovky v nadpisu. Je to jen vytažení konfigurace sdílení z konfigurace serveru do nastavení vlastností filesystému. Nejsem si jistý, jestli je to nutné nebo dokonce vhodné ve filesystému mít.

    Integrace s Linuxem – vítězí Btrfs

    Tady opět jasně vítězí Btrfs, protože ZFS je na Linuxu tak trochu vetřelec. Pokud vím, tak ZFS není dobře integrovatelný s linuxovým VFS (na druhou stranu by integrace s VFS mohla být lepší i u Btrfs, jak už dříve poznamenal Heron), správa paměti a cachování je v ZFS docela komplikovaná a dělaná „po vlastní ose“ (což ale nemusí být nutně špatně, je to optimalizace pro účel, kterému to slouží), POSIX ACL jsou ukládány jako rozšířené atributy, protože nejsou podporovány na ostatních platformách a nemohou tak přepsat nativní ZFS/NFSv4 ACL apod.

    Z uživatelského hlediska asi překvapí, že se nic nepíše do /etc/fstab a nefunguje mount, protože i toto má ZFS řešeno jinak – přes zfs mount/unmount a zpool import/export. Přitom korektní export úložiště je podstatný i jen před tím, než budete disky přenášet do jiného serveru, jinak tam ZFS pool korektně nerozběháte. (A např. ZFSonLinux init skripty na Debianu prý při vypínání stroje dělají jen umount, nikoliv export!)

    Obecně se mi zdá, že je u ZFS na discích je méně metadat, než by člověk čekal, protože v tutoriálu Aarona Toponce je na několika místech varování, ať se nepoužívají potenciálně se měnící odkazy na disky přes /dev/sdx, ale perzistentní /dev/disk/by-id/y, aby nedošlo k záměně zařízení ZFS. Pokud vím, tak u Btrfs je to jedno a jádro si disky najde a správně identifikuje přímo z metadat na blokových zařízeních.

    Stabilita a prověření praxí a časem – vítězí ZFS

    Z vlastní zkušenosti vím, že u Btrfs se dá celkem snadno narazit na problém, který by v produkčním prostředí člověk řešit nechtěl. Faktem je, že stabilizace, ladění a vychytání software chce čas, takže mezi Btrfs, vyvíjeným od roku 2009 (od 2013 označený za stabilní), a ZFS, zdrojové kódy uvolněné 2005 (což tedy byla nějaká ne úplně raná verze), jistě rozdíl ve vyspělosti bude.

    Na druhou stranu je otázka, jak moc se dá spoléhat na vyspělost ZFS na jiných platformách, než domovském Solarisu. Nemám přehled, jak velké procento kódu je sdíleno. A i tak je adaptace kódu z jednoho systému na jiný systém vždycky spojená se zavlečením chyb. ZFS začíná mít má mnoho verzí, a to i z hlediska formátu filesystému na disku.

    To ale nic nemění na faktu, že ZFS je výrazně dospělejší a lépe ověřený (i produkčním provozem) než Btrfs.

    Kompatibilita – vítězí ZFS

    Pod zprávičkou o začlenění ZFS balíčku do Debianu se objevila dobrá poznámka v diskusi, že ZFS tak vlastně začíná být pěkný jednotící filesystém z hlediska kompatibility napříč různými operačními systémy. Btrfs je sice licenčně čistý a dobře integrovaný s Linuxem, ovšem na jiných systémech budete mít s jeho zpřístupněním problém. (I když doufám, že by třeba nakonec něco mohlo být z projektu WinBtrfs.) V případě ZFS s filesystémem budete schopni pracovat na Linuxu, FreeBSD, MacOS X a dalších (modulo případná nekompatibilita verzí formátu ZFS).

    Závěr

    Z uvedeného myslím jasně vyplývá, že Btrfs i ZFS mají svoje silné a slabé stránky. Jako obvykle tedy musíte zvážit svoje potřeby, vybrat vhodnější řešení a vypořádat se s jeho omezeními.

    Vývoj, stabilizace a přijetí Btrfs jde ale pomaleji, než bych si přál. V současnosti, kdy se ZFS chystá do Ubuntu a Debianu, se začínám trošku bát, aby se ZFS nezačal na Linuxu používat tak masivně, že potřeba next-gen filesystému pod Linuxem jím bude více méně uspokojena a vývoj Btrfs úplně ustrne. Byla by to velká škoda – jak můžete vidět výše, Btrfs má co nabídnout a ZFS je přece jen na Linuxu tak trošku veřelec.

           

    Hodnocení: 100 %

            špatnédobré        

    Anketa

    Co raději?
     (53 %)
     (47 %)
    Celkem 125 hlasů

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    AsciiWolf avatar 29.2.2016 02:18 AsciiWolf | skóre: 38 | blog: Blog
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Skvělé srovnání! Tohle by si zasloužilo vyjít jako článek. ;-)
    4.3.2016 22:38 miki.lbc | skóre: 7
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    +1
    5.3.2016 02:27 Sváťa Pátek
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    To ho redakce nemůže ocenit, pokud to nemá mezi Články?
    Cohen avatar 5.3.2016 23:02 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti

    Na článek se to IMHO nehodí, není tam žádný rozumný širší úvod atd. Jsem dostatečně oceněn tím, že se to dostalo do výběru kvalitních linuxových blogpostů, má to solidní skóre v dobré:špatné hodnocení od čtenářů a kladné ohlasy v diskusi. ;-)

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    Josef Kufner avatar 7.3.2016 12:02 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    To je jeden odstavec navíc, kde řekneš, pro jakého čtenáře to je a co se od něj očekává za znalosti. Není nic špatného na odborném článku, kterému většina lidí neporozumí, neboť neznají to, o čem je. (Špatné by bylo, kdyby mu neporozuměli ani ti, pro které je určen.)
    Hello world ! Segmentation fault (core dumped)
    Heron avatar 7.3.2016 16:41 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    +1
    29.2.2016 07:59 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti

    Anketa by byla zajímavější, kdyby tam byla i možnost "něco jiného". Kdyby mi někdo držel pistoli u hlavy, že si z těch dvou musím vybrat, tak bych tam holt BtrFS dal, ale zatím jsem se u svých systémů mohl rozhodovat svobodně, takže nikde není.

    Ale i pak by ta otázka byla příliš obecná. Odpověď totiž může silně záviset na tom, k čemu a jak má být ten filesystém využíván.

    5.3.2016 02:37 Sváťa Pátek
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Na druhou stranu, uživatele nízkolatenčních desktopů, to stejně nezajímá, protože třeba takové snapshoty berou spoustu výkonu. Uživatelé OpenSUSE 13.2 (btrfs default) proto používají raději EXT4.
    Jendа avatar 5.3.2016 03:14 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Nepřijde mi, že by btrfs snapshoty nějak zpomalovaly, ale nemám to na žádném stroji s extrémní I/O zátěží.
    Cohen avatar 5.3.2016 23:06 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Uživatelé OpenSUSE 13.2 (btrfs default) proto používají raději EXT4.

    Tak to se uvádím jako protipříklad, openSUSE používám dlouhá léta na všech svých linuxových ne-serverových strojích a s Btrfs jsem tam začal s radostí experimentovat ještě (tuším o verzi) před tím, než se z něj stal defaultní filesystém.

    Nevím, co přesně je myšleno vlivem snapshotů na výkon. Napadají mne jen dvě věci:

    • Pořízení snapshotu samotného – to je prakticky zadarmo a téměř ihned. A v průběhu práce s filesystémem Btrfs tak jako tak dělá copy-on-write. Jestli při změně bloku odkaz na původní blok označí za volný nebo ne, protože je součástí snapshotu, to je prakticky jedno. Tj. pokud bylo myšleno toto, tak je to problém Btrfs jako takového (zejména CoW, jako základního principu jeho fungování), nikoliv konkrétně snapshotů.
    • Vyrábění snapshotů při aktualizacích balíčků a změnách konfigurace systému – tohle už asi trošku zdržovat může, protože Snapper, který se k tomu používá, musí provést nějaké operace navíc, než jen samotné udělání snapshotů. To se ale děje jen sem tam (jen když se aktualizuje systém/něco mění přes Yast apod.) a navíc je to z mého pohledu stejně naprosto zanedbatelná cena v porovnání s tím, že můžu extrémně snadno rollbacknout nepovedené aktualizace systému, podívat se, co se kdy měnilo v konfiguraci atd.
    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    5.3.2016 23:58 Sváťa Pátek
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Měl jsem to na plotnovém disku 7200ot/m. Ano ten pokles výkonu byl vždy kdy se spustil Snapper (dost často) a mluvil jsem o nízkolatenčním desktopu, třeba jsem sledoval tv a při této činnosti vypadával obraz někdy i zvuk. Takže kdybych chtěl něco (film) nahrát mohl bych to poté hned smazat. Když jsem spustlil snapper gui a chtěl tam něco vidět obě cpu 2x2.4GHz byly na 100%.
    Heron avatar 6.3.2016 08:19 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Jestli při změně bloku odkaz na původní blok označí za volný nebo ne, protože je součástí snapshotu, to je prakticky jedno.

    Není to jedno z hlediska fragmentace toho souboru. Pokud se soubor mění často, tak alokátor může ten blok umístit vedle (zvýší se fragmentace) a při jeho dalším update zase na původní místo (sníží se fragmentace). Pokud je původní blok stále odkazován z nějaké jiné kopie (reflink, snapshot), tak při dalším update musí mají další volný blok (který už může být na disku o hodně dál, než původní bloky souboru). (Jestli to takhle btrfs dělá nevím, takto se to někdy dělá v multigeneračních db.) V praxi potom pozoruji, že subvolume se snapshoty se updatuje o něco pomaleji, než sub bez snapshotů. (Což ale může být dáno i něčím jiným, alokátor může mít problém najít volné bloky.) Není to nijak významné, ale lze si toho všimnout. (A to se bavíme o sub, která má několik tisíc snapů a updatuje se poměrně často, takže těch kopií bloků tam bude hodně.)

    navíc je to z mého pohledu stejně naprosto zanedbatelná cena

    Asi tak.

    Heron avatar 29.2.2016 08:45 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Skvělý článek!!!
    Flexibilita zmenšování úložiště
    U mě před lety vyhrálo BtrFS nad ZFS právě z důvodu flexibility multidevice. Přidat, odebrat, kdykoliv, cokoliv (s podmínkou aktuálního typu raidu a volného místa).

    Chystám se ještě na obecný potlach o "dokonalém" fs (z mého pohledu). Co bych velmi u btrfs ocenil by byla možnost vybrat si raid profil per subvolume. ZFS má tohle přesně naopak, tam je raid definován pro vdev, který se jako celek strká do zpoolu. Ale já bych rád FS, který disky bere jen jako "skladiště bloků" a redundanci si řeší tak, že bloky souboru umístí na příslušný počet zařízení. Takže mít subvolume typu raid1, raid0 apod. Nevím, jak daleko od toho btrfs je, toto už dnes v podstatě platí pro celý fs (za běhu lze měnit raid profil celého fs, to znamená, že během této operace jsou některá data uložena dle starého profilu a některá dle nového - a je to zcela konzistentní). Snad by nemuselo být tak těžké implementovat profil per subvolume (i když ten multidevice alokátor bloků různých profilů bych teda psát nechtěl).
    29.2.2016 09:18 Filip Jirsák
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Jak je to s tou odolností proti výpadkům? Když se data rozdělují mezi jednotlivá VDEV, při výpadku jednoho VDEV stejně přijdu o bloky na něm uložené. Podle mne je ta pravděpodobnost ztráty dat stejná pro btrfs i ZFS – rozdíl je jenom v tom, že u ZFS je sice nižší pravděpodobnost, že vůbec přijdu o nějaká data, ale když už o ně přijdu, bude jich víc, než u btrfs. Třeba u ZFS je pravděpodobnost 1/x že přijdu o 1/y dat, zatímco u btrfs je pravděpodobnost 2/x, že přijdu o 1/2y dat. Nebo jsem něco přehlédl?
    2.3.2016 13:58 Sten
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Rozdíl je v tom, že v rámci jednoho VDEV proběhne synchronizace mnohem rychleji, než když se dělá synchronizace nad obrovským RAIDem, takže se netráví mnoho času v degradovaném stavu, kdy hrozí fatální selhání druhého disku.
    29.2.2016 09:24 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    ZFS je prasopes. Tím mám na mysli, že se snaží řešit bloková zařízení i souborový systém současně. Jenže otázka zní: Jaký má smysl používat jednu a tu samovou věc na všechno, když si bloková zařízení mohu řešit přes LVM a souborový systém zvlášť?

    Je to čistě o osobních preferencích. Já preferuji aplikace, které nejsou všeobjímající, ale snaží se pokud možno maximálně dobře to co dělají. Je pak totiž mnohem snazší odhalit problémové místo. A také lze situaci mnohem flexibilněji řešit.
    29.2.2016 09:40 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Taky mám radši univerzální řešení, ale v tomhle případě má integrace své výhody, např. u snapshotu na úrovni blokového zařízení nelze garantovat, že bude obsahovat konzistentní obraz filesystému. U takového RAIDu už jsem ale o vhodnosti implementace na úrovni filesystému přesvědčen výrazně méně.
    29.2.2016 10:35 Václav Vanc | skóre: 14
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    RAID tam musí být integrován, kvůli opravě dat při špatném kontrolním součtu.
    Jendа avatar 29.2.2016 16:59 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Ne, stačilo by, kdyby FS uměl blokovému RAIDu říct, že tohle je špatně, a jestli nemá druhou kopii. Nebo by checksumy mohl řešit rovnou blokový RAID, jako to má IBM v AS400.

    Mimochodem už jste někdo viděl nějakou silent data corruption, pokud možno na počítači s ECC?
    Cohen avatar 29.2.2016 17:04 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Mimochodem už jste někdo viděl nějakou silent data corruption, pokud možno na počítači s ECC?

    Právě že možná viděl...

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    Jendа avatar 29.2.2016 18:10 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Na non-ECC počítači bych už nevěřil ničemu…
    Cohen avatar 29.2.2016 21:09 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti

    Před chvílí jsem četl tohle, a řeknu vám, ta čísla tam uváděná jsou děsivá. Docela žasnu, že běžné desktopy a notebooky bez ECC RAM vůbec nějak fungují.

    Do příštího desktopu se budu snažit dostat ECC paměť, ale bojím se, že to narazí hlavně na omezeném výběru desek. :-/ U notebooku je to prakticky marné (krom pár modelů superdrahých mobilních pracovních stanic).

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    Grunt avatar 29.2.2016 23:11 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Ono obecně jak to jde s produkční kvalitou médií stále víc a víc z kopce bych se vůbec nedivil kdyby procesor měl třeba na add <1>, 1 jednou za milion instrukcí povoleno vrátit třeba 3. A nebo taky -2147483648. To bych asi bral radši ten co vrací na 1+1 ty trojky :-)
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    Heron avatar 1.3.2016 10:07 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Takových děsivých čísel po světě chodí.

    Hromadu let kontroluju svá data přes sha512 (jak šel čas tak přes různé fce) a zatím přesně 0 změn. Dlouho na FS typu extX, potom XFS (takže bez vlastního csum), teď 5 let btrfs. Objem dat postupně roste, aktuálně něco přes 10TB. Za nějakých už skoro 15 let vůbec nic.

    Co se týče ECC, na serverech máme pochopitelně jen ECC, hodně přes 1TB RAM celkem a chyby z ECC chodí tak 3x do roka vždy jen z jednoho modulu, který dřív nebo později odejde (resp. naopak: pokud chodí chyby ECC, tak to zatím vždy znamenalo chybu modulu paměti).

    Doma ECC nemám, btrfs křičelo chyby csum jen jednou a memtest okamžitě odhalil vadnou ram (takže díky btrfs jsem na to přišel relativně rychle, modul vyměnil a data zkontroloval proti záloze).

    CPU zahlásil ECC chybu za poslední 3 roky jen 2x (L3 cache).

    Takže tak. Chápu, že zkušenosti z řádů desítek TB diskového prostoru a jednotek TB RAM se (obzvláště na českém fóru) mohou zdát směšná, ale nám ten HW stačí.

    Tohle je spíš návod jak k tomu přistupovat. Hlášení ECC chyb mnohem víc než jako systém pro korekci dat funguje jako včasné varování, podobně jako smart u disku. Pokud se objeví první ecc chyba (nebo první realocated sector), je na čase ten hw vyměnit a na nic nečekat.

    3.3.2016 15:52 pasky | skóre: 3 | blog: pasky
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Že ta čísla nedávají žádný smysl snad potvrdí každý, kdo si nově koupený počítač či RAMky pravidelně testuje několik hodin až dní memtestem.

    Mýtus pochází z jednoho známého paperu "z Google" (i když hlavní autor z Google není), který není moc dobrý (resp. z naměřených dat nedochází ke správným závěrům) - http://research.google.com/pubs/pub35162.html. Problém je, že ta studie je dělaná nad ECC DIMMkami a naivní čtenář si přečte, že pokud pro ECC DIMMky platí, že "our per-DIMM rates of correctable errors translate to an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit," je to zároveň počet chyb, které se odehrávají na DIMMkách, které ECC nemají!

    Takové paměti jsou ale k ničemu a evidentně to nemá žádný odraz v realitě. Když jsem spravoval síť několika desítek pracovních stanic, ECC DIMM jsme nepoužívali, ale každou novou stanici či server jsme nechali memtestovat 3-7 dní (stejně se nakupuje před Vánoci :) a v případě chyby se šlo na reklamaci (tak 10% případů). To bychom moc počítačů neměli...

    Jaké je alternativní rozuzlení? Že QA u ECC DIMM projdou i ty trochu vadné, pokud dělají konzistentně opravitelné chyby, zatímco ne-ECC DIMM neprojdou.

    Výhoda ECC tedy spočívá v tom, že pokud už se chyba stane, dozvíte se o tom (a s tím může být přeci jen spojená trochu menší frekvence neopravitelných chyb, ale rozhodně ne tak výrazná).
    Jendа avatar 3.3.2016 19:33 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    A já se divil když jsem tam nedávno přišel a vypadalo to, že staví memtest cluster :-)
    každou novou stanici či server jsme nechali memtestovat 3-7 dní
    Nemůže se ta chyba projevit jen tehdy, když se to zapíše, nechá chvíli odležet, a pak přečte? Přičemž memtest zapisuje a čte menší bloky.

    Jinak já se u non-ECC počítačů nebojím ani tak náhodných chyb občas, jako spíš toho, že od náhodných bitflipů ke spuštění memtestu většinou vede spousta debugování ve skutečnosti funkčního softwaru.
    3.3.2016 20:40 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Nemůže se ta chyba projevit jen tehdy, když se to zapíše, nechá chvíli odležet, a pak přečte? Přičemž memtest zapisuje a čte menší bloky.

    Vzpomínám si, že memtest míval i nějaký "decay" test (defaultně se nespouštěl), kde se IIRC popsala celá paměť, pak se 90 minut nedělo nic a potom se obsah zkontroloval.

    10.3.2016 19:05 alkoholik | skóre: 35 | blog: Alkoholik
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    A studii o ovlivnovani sousednich bitu znete?
    Jendа avatar 11.3.2016 01:24 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Ano, a nový memtest tohle zkouší taky (test se jmenuje Rowhammer).
    Grunt avatar 29.2.2016 22:53 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Tohle jsem nějak minul a možná se od posledně něco změnilo ale nevisí náhodou u btrfs takový obří červený rámeček a ještě vykřičník nebo dva v něm s nápisem: „Btrfs je vývojovém stádiu! NEPOUŽÍVEJTE BTRFS NA PRODUKČNÍM SYSTÉMU POKUD NECHCETE PŘIJÍT O DATA!“ nebo tak něco?
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    Cohen avatar 29.2.2016 23:12 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Tak strašné už to není. V Btrfs Wiki je psáno:
    The status of btrfs was experimental for a long time, but the the core functionality is considered good enough for daily use.

    Ano, doporučuje se mít poslední kernel, a je tam zdůrazněné mít zálohy a být připraven je použít, to ale snad platí vždy, ne?

    Taky pomalu roste počet „produkčních“ uživatelů.

    Výše popsané tedy rozhodně nepovažuji za něco, co by Btrfs neměl přežít (a však to taky data nijak neohrozilo).

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    Grunt avatar 29.2.2016 23:19 Grunt | skóre: 22 | blog: Expresivní zabručení | Lanžhot
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    No já jen že se stejnou chybou jsem se setkal taky když jsem si jen tak z radosti testoval Btrfs na flash disku. Systém šlapal jak hodinky, najednou z ničeho nic corrupted data na disku, za chvíli ještě víc chyb, zpanikařilo jádro, po pokusu data obnovit jsem se dostal do situace kdy jsem to radši celé naformátoval a vrátil si zpět ext4 který bez problémů fungoval nějaký ten další rok. Přisoudil jsem to vlastní blbosti, protože ty obří červené rámečky na možnost tohoto chování tam opravdu jsou.
    Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
    2.3.2016 14:26 Sten
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Ne, je tam, že má některé vlastnosti, které jsou ve vývojovém stádiu (např. paritní RAIDy), pokud je nebudete používat, je btrfs (s dostatečně novým jádrem) stabilní.
    29.2.2016 17:08 Roger
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Nevím, jestli se to počítá jako "silent data corruption", ale mně už takhle btrfs v RAID1 zachránilo data, když přidání testovacího disku rozhodilo ty existující a začala se poškozovat data.

    Všiml jsem si toho v kernelovém logu, kam si btrfs stěžovalo (a vzniklé problémy řešilo přes kopii dat v onom RAIDu).
    Jendа avatar 29.2.2016 18:10 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Poškozovat jakým způsobem?
    29.2.2016 19:21 Roger
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Pokud mi pamět slouží, chyby při čtení - neseděly checksumy.
    Cohen avatar 29.2.2016 20:56 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti

    Nehlásil ovšem chyby už disk, tj. nebylo z logu poznat, že došlo k chybě čtení z hardware? Nebo to opravdu chytal až Btrfs přes nesedící kontrolní součty?

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    29.2.2016 17:49 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Jo, vcelku bezna vec - aspon na zaloznim poli, kde uz je nejakych 40 3TB disku, 2-3 bloky za cca pul roku.
    --- vpsFree.cz --- Virtuální servery svobodně
    Jendа avatar 29.2.2016 18:09 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    A to fakt přečte jiná data a nehodí to žádnou chybu?

    To pole je SATA přímo do počítače, a je tam ECC?
    Jendа avatar 29.2.2016 18:11 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Nešlo by, prosím prosím, přidat do jaderného modulu, že to kromě chyby vypíše i hexdump toho bloku? fakt by mě zajímalo, jestli jsou to flipy jednoho bitu, nebo je třeba celý blok nulový.
    29.2.2016 21:16 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    To je zajimavy napad, az se v tom budu zas vrtat, zkusim se podivat, kam by se to dalo placnout. Nejaky vhodne umisteny printk() by mohl stacit. Jinak jsou to asi nejvetsi sh*t disky, co jsem potkal od WD - RED edice, 3TB kapacita, pres SAS2 expandery pripojeny na SAS2 PCIe HBA k jednomu z dvou socketu. Jsou tam ECC DDR3 pameti.
    --- vpsFree.cz --- Virtuální servery svobodně
    29.2.2016 19:38 Michal2
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Já zatím čekám. 8 kusu 3TB WD RED v RAIDZ2, zaplněno 14TB, 3 roky, scrub každý měsíc. Doposud 0 odhalených chyb. Statisticky by jich už mělo být spoustu (unrecoverable error rate 10^14).
    8.3.2016 00:31 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    např. u snapshotu na úrovni blokového zařízení nelze garantovat, že bude obsahovat konzistentní obraz filesystému
    Jaktože ne? Filesystém se dá ručně zmrazit a podle manuálové stránky fsfreeze to dokonce LVM dělá automaticky, když se po něm chce vytvoření snapshotu.
    Quando omni flunkus moritati
    cezz avatar 8.3.2016 17:05 cezz | skóre: 24 | blog: dm6 | Žilina
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Oprav ma ak sa mylim, ale pokial viem toto silno zavisi na podpore konkretneho filesystemu, cize nie kazdy FS vie LVM takto zmrazit.
    Computers are not intelligent. They only think they are.
    9.3.2016 01:13 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    To jasně, ale třeba ext4 a xfs (které - hádám - mají na Linuxu docela velký podíl) to umí.
    Quando omni flunkus moritati
    9.3.2016 23:37 Sten
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Až na FAT to umí snad každý. Snapshot na úrovni blokového zařízení je totéž, jako když vypadne proud. Každý moderní souborový systém se s tím umí vyrovnat tak, aby zůstal konzistentní.
    cezz avatar 10.3.2016 11:00 cezz | skóre: 24 | blog: dm6 | Žilina
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Crash consistency a fsfreeze su dve odlisne veci. Ale inak mas pravdu, vacsina beznych FS fsfreeze podporuje.
    Computers are not intelligent. They only think they are.
    29.2.2016 15:42 VSi | skóre: 28
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Jaký má smysl používat jednu a tu samovou věc na všechno, když si bloková zařízení mohu řešit přes LVM a souborový systém zvlášť?
    LVM snapshoty jsou výkonnostně nepoužitelné. Jak mdraid tak LVM neumí pracovat s informací o neobsazeném místě (mohlo by to asi fungovat přes TRIM, ale není to tam). RAID zas dokáže těžit z kontrolních součtů, pokud o nich ví.

    Velkou část věcí by asi šlo nějak vyřešit i přes oddělené vrstvy, ale integrace přináší výkonnostní a implementační výhody.
    29.2.2016 21:39 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    A kdo tady psal o snapshotování na úrovni LVM? Jednak jak správně píšeš, je to výkonostně pro kočku a pak - je to zbytečné.
    29.2.2016 10:02 Jindra
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    GNU GPL kód Btrfs je mnohem příjemnější,
    ... jestli na ZFS založí svůj produkt,
    Z uvedeného myslím jasně vyplývá, že Btrfs i ZFS mají svoje silné a slabé stránky. Jako obvykle tedy musíte zvážit svoje potřeby, vybrat vhodnější řešení a vypořádat se s jeho omezeními.
    Heron avatar 29.2.2016 10:28 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Pokud vím, tak se ZFS není dobře integrovatelný s linuxovým VFS
    To někdy ani btrfs. Pokud je subvolume s daty, udělá se její snapshot (takže subvolume a její snapshot vede na zcela stejné bloky), tak při čtení subvolume a následně jejího snapshotu se ty bloky čtou z disku znovu (nedostanou se do žádné iocache, resp se tam dostanou 2x - jednou pro tu subvolume a podruhé pro snapshot - pokud je dostatek paměti).

    Toto není problém při běžném používání, ale pokud někdo intenzivně pracuje napříč snapshoty (které se příliš nemění, takže souboru odkazují na tytéž bloky), tak je to mnohem pomalejší, než by to mohlo být. Stejně tak (nepřekvapivě) pro kopie pomocí reflinků.

    Cohen avatar 29.2.2016 11:42 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    29.2.2016 14:21 integrace s OS
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Krom domovského Solarisu je ZFS dobře integrováno (už dlouho) třeba do FreeBSD (údajně, na zdrojáky sem nekoukal). FreeNAS je tuším postaven nad FreeBSD (a lidi zhusta ZFS ve FreeNASu používají).
    29.2.2016 15:02 Adam
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Nevíte jak je to s výkonem a podporou pro SSD? Vím, že SSD mívaly problémy se zápisem a čtením velkého množství malých souborů. Je tu nějaký pozorovatelný rozdíl?
    2.3.2016 14:22 Sten
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Nevím, jak je to u ZFS, ale btrfs podporuje TRIM, COW je obecně mnohem příjemnější pro SSD disky než přepisy in-place, malé zápisy jsou clusterované, čtení nepoužívá optimalizace seeků a velké množství malých souborů řeší tím, že malé soubory jsou uloženy v bloku se svými metadaty.
    2.3.2016 23:16 Adam
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    To tak nějak souhlasí s mým hrubým odhadem situace :)
    29.2.2016 16:23 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    ZFS ma jine cile, nez BTRFS. ZFS chce byt storage system, ne filesystem. Cili si resi i svoje cachovani, scheduling IO operaci a dalsi veci. BTRFS v tomhle zustava pri zemi, pokud vim. A nejlepsi je, ze se ZFS nesnazi s BTRFS soutezit, chlapci proste delaji svoji vec a neresi, co si kde linuxaci matlaji po svem s jejich typickym vyvojovym modelem. Vyvojari ZFS resi efektivni ukladani a manipulaci se stovkami TB dat v nejruznejsich hierarchiich. ZFS vzniklo na zaklade potreby ukladat data, BTRFS je historicky hracka cmasona nad modifikovanymi B stromy, z ktere chtel vytriskat featury, ktere linuxaci zavideli ZFSkarum. Pro nejblizsich X let verim OpenZFS a jeho vyvojarske bazi. BTRFS planuju zkusit (a tim nemyslim na jednom disku) az tak v RHEL 8.
    --- vpsFree.cz --- Virtuální servery svobodně
    29.2.2016 21:47 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Řešit storage v rámci jednoho fyzického stroje je přežitek. Budoucnost mají distribuovaná úložiště. A pro ně je vyvíjený jiný prasopes - Ceph. A pro účely distribuovaného úložiště je vhodnější mít na těch nodech Btrfs, než ZFSm protože je flexibilnější. Distribuované systémy totiž mají datové objekty uloženy jako soubory.
    2.3.2016 14:51 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Zrovnatak, jako nikdy nebudu pouzivat Docker, protoze je zrovna hyper in a cool, nebudu pouzivat ani ty object story, ktere jsou podle tebe budoucnost. Stackovat takhle vrstvy nad sebe, delejte si to kdo chcete, ale mne z toho vynechte, ja maximum, co jsem ochotny prijmout, vidim na DRBD. Urcite ne filesystemy, ktere jsou rozdelene na soubory a ulozene na dalsich filesystemech. A uz vubec ne puvodem linuxove FS, pac saji vsechny do jednoho.
    --- vpsFree.cz --- Virtuální servery svobodně
    2.3.2016 14:55 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    A uz vubec ne Gluster, abych jeste lital 40x pres userspace, kdyz chci dostat data. Muj pozadavek je, aby to, co postavim ted, bylo pouzitelne i s NVMe SSD. Gluster neni ani zda-le-ka. A malo co je, jedine svetlo na konci tunelu aktualne vypada byt DRBD 9. Cekam na 40GE a IB QDR karty, abych si to mohl poradneji osahat.
    --- vpsFree.cz --- Virtuální servery svobodně
    2.3.2016 15:54 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Pleteš si jabka s hruškama. Není jenom GlusterFS. Nad jedním fyzickým strojem rychlé úložiště s kapacitou v petabajtech prostě nepostavíš.
    2.3.2016 19:05 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Prd si pletu. Ty mi vnucujes use-case, ktery nemam. Ja chci clustered storage pro kontejnery, kontejnery chci mit nad ZFS protoze XY duvodu a na to potrebuju distribuovany block storage. Neco, co mi da blockdev ve finale, nad kterym muzu jet ZFS. DRBD. Nebo co chlapci ze SUSE vymysli s network RAIDem, az se dostanou k implementaci 5/6, to by mohla byt sranda. Ty tvrdis, ze co resi ZFS/BTRFS stejne neni relevantni, protoze ~cca kazdy bude chtit ukladat distribuovane PB dat idealne po velkych souborech. Ja to tedy vidim uplne jinak, ja potrebuju ukladat stamiliony malinkych souboru a mit k nim pristup tak rychly, ze nepoznam, jestli je to pod na siti nebo ne. Da se to udelat, ale ne s nicim, co tu prohlasujes za budoucnost ukladani dat. :-)
    --- vpsFree.cz --- Virtuální servery svobodně
    2.3.2016 19:59 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    V neděli by ses mohl dozvědět víc. Mám s DRBD několikaleté zkušenosti, a cestu kterou chtějí prošlapat chlapci ze SUSE jsem prošel ještě předtím, takže vím, že to nemá budoucnost.
    3.3.2016 00:18 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Urcite se prijdu podivat, tesim se ;-)
    --- vpsFree.cz --- Virtuální servery svobodně
    2.3.2016 15:58 Aleš Kapica | skóre: 46 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Jo a Linbit znovu vymýšlí kolo. Koukni se na Sheepdog a Accelio.
    8.3.2016 00:38 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    ja maximum, co jsem ochotny prijmout, vidim na DRBD
    Jo tak to bych zrovna teď nejradši vzal a vyhodil z okna. Náhodné vytuhnutí drbdsetup v kernelu na 10 minut fakt nepotěší.
    Quando omni flunkus moritati
    2.3.2016 16:37 melkors | skóre: 13 | blog: kdo_chce_kam
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Dovolil bych si upozornit take na SheepDog - sice jeste neprosel do stable, ale konce brezna by melo byt 1.0-rc0
    oryctolagus avatar 29.2.2016 19:50 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    V Btrfs je snapshot vlastně další podadresář (nebo možná spíše mountpoint) někde v adresářové struktuře. V ZFS běžně vidět není.
    Snapshoty jsou v ZFS vidět pomocí zfs list -t snap nebo zfs list -t all.

    Jinak jak je na tom btrfs s řízením, který uživatel může co dělat? Tzn. vytvářet subvolumes / snapshoty apod.
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    Cohen avatar 29.2.2016 21:03 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    V Btrfs je snapshot vlastně další podadresář (nebo možná spíše mountpoint) někde v adresářové struktuře. V ZFS běžně vidět není.
    Snapshoty jsou v ZFS vidět pomocí zfs list -t snap nebo zfs list -t all.

    Jasně, ale tady mi šlo o to, aby to bylo dostupné jako běžné soubory, které si prohlédnu libovolným programem pracujícím se soubory na disku.

    Jinak jak je na tom btrfs s řízením, který uživatel může co dělat? Tzn. vytvářet subvolumes / snapshoty apod.

    Tohle má možnosti jen triviální. Bez nahlédnutí do dokumentace: Každý uživatel smí vytvořit subvolume/snapshot, ale jen root ho smí smazat. Mazání snapshotů lze povolit i pro běžné uživatele přes mount volbu. Myslím, že nic další ani nakonfigurovat nelze (ale do dokumentace jsme nekoukal).

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    29.2.2016 21:42 Michal2
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Kazdy snapshot v ZFS je pristupny jako podasresar v (implicitne zcela skrytem) podadtresari /pool/subvolume/.zfs/snapshots

    cd /data/virtual/.zfs
    root@zfs:/data/virtual/.zfs/snapshot# ls
    snap_daily-2016-02-23-0002   snap_hourly-2016-02-29-1601
    snap_daily-2016-02-24-0002   snap_hourly-2016-02-29-1701
    snap_daily-2016-02-25-0002   snap_hourly-2016-02-29-1801
    snap_daily-2016-02-26-0002   snap_hourly-2016-02-29-1901
    snap_daily-2016-02-27-0002   snap_hourly-2016-02-29-2001
    snap_daily-2016-02-28-0002   snap_initial-2014-06-29-0003
    snap_daily-2016-02-29-0002   snap_monthly-2015-03-01-0204
    snap_hourly-2016-02-28-2101  snap_monthly-2015-04-01-0104
    snap_hourly-2016-02-28-2201  snap_monthly-2015-05-01-0104
    snap_hourly-2016-02-28-2301  snap_monthly-2015-06-01-0104
    snap_hourly-2016-02-29-0001  snap_monthly-2015-07-01-0104
    snap_hourly-2016-02-29-0101  snap_monthly-2015-08-01-0104
    snap_hourly-2016-02-29-0201  snap_monthly-2015-09-01-0104
    snap_hourly-2016-02-29-0301  snap_monthly-2015-10-01-0104
    snap_hourly-2016-02-29-0401  snap_monthly-2015-11-01-0204
    snap_hourly-2016-02-29-0501  snap_monthly-2015-12-01-0204
    snap_hourly-2016-02-29-0601  snap_monthly-2016-01-01-0204
    snap_hourly-2016-02-29-0701  snap_monthly-2016-02-01-0204
    snap_hourly-2016-02-29-0801  snap_weekly-2016-01-31-0103
    snap_hourly-2016-02-29-0901  snap_weekly-2016-02-07-0103
    snap_hourly-2016-02-29-1001  snap_weekly-2016-02-14-0103
    snap_hourly-2016-02-29-1101  snap_weekly-2016-02-21-0103
    snap_hourly-2016-02-29-1201  snap_weekly-2016-02-28-0103
    snap_hourly-2016-02-29-1301  snap_yearly-2015-01-01-0305
    snap_hourly-2016-02-29-1401  snap_yearly-2016-01-01-0305
    snap_hourly-2016-02-29-1501
    
    Normalne to funguje. Fakt nechapu, proc v tom clanku pises takove veci. To klade dost vylky otaznik i na ostatni zjisteni.
    Cohen avatar 29.2.2016 21:51 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti

    Ale vždyť to tam napsané je:

    existuje skrytý adresář .zfs, který je ale ve výchozí konfiguraci ZFS skrytý více, než by člověk čekal, nevypíše ho ani utilita ls, i když se do adresáře dá vstoupit:
    # ls -a /tank/test
    ./  ../  boot.tar  text.tar  text.tar.2
    # cd /tank/test/.zfs/
    # ls -a
    ./  ../  shares/  snapshot/
    # zfs set snapdir=visible tank/test
    # ls -a /tank/test
    ./  ../  boot.tar  text.tar  text.tar.2  .zfs/
    
    Přes obsah .zfs se tedy asi člověk k jednotlivým souborům dostane, aniž by musel provést vyloženě rollback datasetu k danému snapshotu
    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    1.3.2016 01:34 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    .zfs je skryty ve vypisu adresaru defaultne kvuli zalohovacim nastrojum. Jinak v nem taky funguje rmdir/mkdir na vyrabeni/mazani snapshotu.
    --- vpsFree.cz --- Virtuální servery svobodně
    Bystroushaak avatar 1.3.2016 02:30 Bystroushaak | skóre: 32 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    V čem jsi to psal, že to máš tak pěkně naformátované?
    Cohen avatar 1.3.2016 07:47 Cohen | skóre: 21 | blog: Drobnosti | Brno
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti

    Bohužel musím zklamat, žádné pěkné automatické řešení – jen ruční práce + grep & vim pro výběr položek obsahu a jeho naformátování. :-/

    OpenPGP key fingerprint: 489C 5EC8 0FD6 2BE8 9E59 B4F7 19C1 3E8C E0F5 DB61 (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
    Bedňa avatar 2.3.2016 21:29 Bedňa | skóre: 33 | blog: Žumpa | Horňany
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Ale aj tak dík za prácu. Je veľa rozsiahlich blogov kde to človek spraí Tl;DR, ale tento fakt zaujal.
    Pokecajte si s umelou stupiditou na http://www.kernelultras.org/
    2.3.2016 14:10 Sten
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    Snapshot není něco jiného než pododdíl, ale je to druh pododdílu, který vznikl jako snapshot jiného pododdílu místo jako prázdný strom (btrfs subvolume create) nebo z jiného souborového systému.
    kyknos avatar 4.3.2016 20:50 kyknos | skóre: 18 | blog: Quid novi? | Ranša Rosa
    Rozbalit Rozbalit vše Re: Btrfs vs ZFS – srovnání pro a proti
    To je jako vybírat si mezi shnilými fugu jatýrky a plesnivou kulajdou z Amanita phalloides.
    So the Nationalists and the Socialists have the same policy on Brexit. They should get together and form a...

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.