Krátká historie Btrfs

25. 8. 2009 | Jirka Bourek | Jaderné noviny | 16732×

Btrfs bývá označován za budoucnost linuxových souborových systémů. Přečtěte si, co vedlo k jeho vzniku, kdo za ním stojí, jak se liší od ZFS a jak bude jeho vývoj pokračovat.

Obsah

• Btrfs: Před historií
• Btrfs: Začátek
• Btrfs: Politika
• Btrfs: Stručné srovnání se ZFS
• Btrfs: Co dál?

Originál tohoto článku pro lwn.net napsala Valerie Aurora (dříve Henson).

Pravděpodobně jste slyšeli o tom novém hustém týpkovi ze sídliště souborových systémů, btrfs (v angličtině vyslovováno „butter-eff-ess“) – konec konců Linus Torvalds ho používá jako kořenový souborový systém na jednom ze svých laptopů. Možná o něm ale nevíte o moc víc než několik klíčových slov na vysoké úrovni – kopírování při zápisu, kontrolní součty, zapisovatelné snímky [snapshot] – a pár senzačních příběhů – benchmarky na Phoronixu, btrfs vykrádá ZFS, btrfs je tajný plán Oraclu pro nadvládu nad Linuxem atd. Když dojde na souborové systémy, je těžké odlišit pravdu od řečí hanebných pomlouvačů: Kód je příliš komplexní, charakteristiky příliš přehnané a uživatelé jsou naštvaní, když přijdou o data. Věci nejde vyřešit ani bitvou benchmarků: Zátěže souborového systému se divoce liší, takže je možné přijít s rozumným argumentem, proč je kterýkoliv benchmark naprosto irelevantní nebo kriticky důležitý.

V tomto článku se podíváme do zákulisí návrhu a vývoje btrfs na mnoha úrovních – technické, politické, osobní – a budeme ho sledovat od jeho počátků v dílně po současnou pozici Linusova kořenového souborového systému. Znalost pozadí a motivace u každého kroku vám pomůže pochopit, proč se na btrfs začalo pracovat, jak funguje a kam bude směrovat v budoucnu. Na konci byste měli být schopni i strávit popis formátu btrfs na disku.

Upozornění: Musím upozornit na dvě věci: Za prvé, několik let jsem v Sunu pracovala na ZFS. Za druhé, už jsem byla předvolána k výpovědi při různých soudních přích mezi Sunem a NetApp a ráda bych se vyhnula tomu, že bych jim poskytla jakoukoliv záminku mě předvolat znovu. Budu se snažit být férová, čestná a puntičkářsky přesná.

Btrfs: Před historií

Představte si, že jste vývojář souborových systémů pro Linux. Je rok 2007 a jste na Linux Storage and File systems workshop. S linuxovými souborovými systémy to vypadá bledě: Reiserfs, který má problémy s kvalitou a neudržitelným modelem financování, právě ztratil veškerou důvěryhodnost, protože Hans Reiser byl před pár měsíci zatčen. ext4 je stále ve vývoji; ve skutečnosti se dokonce ještě ani nenazývá ext4. A co je důležité, ext4 je pouze přímočaré rozšíření 30 let starého formátu a co se vlastností týče, je světelné roky za konkurencí. Firmy ve stejné době omezují financování vývoje Linuxu; oddělení Linuxu v IBM končí období hájení a potřebuje ukázat ziskovost. Další firmy se bojí blížící se recese a výzkum hází přes palubu. Chtějí projekty, kde se čas do dokončení počítá v měsících, ne letech.

Věčně doufající, vývojáři souborových systémů se sešli i tak. Protože se workshop koná společně s USENIX FAST '07, předneslo na něm několik výzkumníků ze školství i průmyslu své nápady. Jedním z nich byl Ohad Rodeh, který vyvinul druh b-stromu, který je přátelský ke kopírování při zápisu [PDF]. Pokud začneme od začátku, b-stromy jsou ve své přirozené formě s COW [copy-on-write, kopírování při zápisu] značně nekompatibilní. Listy stromu jsou spojeny dohromady, takže když se pozice jednoho listu změní (zápisem, což implikuje kopírování do nového bloku), odkaz v sousedním listě se mění, což spustí další kopírování při zápisu a změnu pozice, což změní odkaz v dalším listu… Výsledkem je, že celý b-strom musí být od začátku do konce přepsán, kdykoliv se změní jeden list.

Ohadovy b-stromy jsou jiné: Za prvé se zbavil odkazů mezi listy ve stromě – což také „vyhazuje spoustu existující literatury o b-stromech“, jak říká ve svých slidech [PDF] – ale ponechává dost vlastností b-stromů, aby byly stále užitečné. (To je poměrně standardní podoba b-stromů v souborových systémech, občas se nazývají „b+stromy“.) Přidal nějaké algoritmy pro procházení stromem, které využívají čítání odkazů, aby se omezila velikost části stromu, kterou je nutné projít, když se maže snímek, stejně jako pár dalších věcí – proaktivní dělení a spojování vnitřních uzlů, aby vkládání a mazání nepotřebovalo žádné procházení [backtracing]. Výsledkem je jednoduchá, robustní datová struktura, která velmi efektivně sleduje rozsahy [extent] (skupiny spojitých datových bloků) v souborovém systému postaveném na COW. Ohad vlastně vytvořil prototyp systému před několika lety, ale s touto oblastí výzkumu skončil a chtěl jenom, aby někdo vzal jeho b-stromy přátelské pro COW a dobře je využil.

Btrfs: Začátek

Chris Mason tyhle b-stromy přátelské pro COW vzal a pracoval s nimi dále. V té době Chris pracoval na Reiserfs, kde se hodně naučil o tom, co v souborovém systému dělat, a co ne. Reiserfs měl několik hezkých vlastností – shlukování malých souborů, b-stromy pro rychlé vyhledávání, flexibilní rozvržení – nicméně implementace byla nahodilá a ad hoc. Kódové cesty se divoce množily a s nimi i potenciální chyby.

Chris měl nápad: Co kdyby všechno v souborovém systému – inody, data souborů, záznamy v adresáři, bitové mapy – byly položky v b-stromě s kopírováním při zápisu? Všechny zápisy a čtení by procházely stejnou cestou kódu, takovou, která by všechny položky sloučila do jednoho uzlu v b-stromě a nechala je tam bez starosti o jejich typ. Pak stačí kód napsat jednou a získáte kontrolní součty, čítání odkazů (pro snímky), kompresi, fragmentaci atd. pro cokoliv v souborovém systému.

Proto Chris přišel s následující základní strukturou btrfs („btrfs“ je zkratka pro "b-tree file system") – btrfs se skládá ze tří typů struktur na disku: hlaviček bloků, klíčů a položek, které jsou aktuálně definovány takto:

struct btrfs_header {
    u8 csum[32];
    u8 fsid[16];
    __le64 blocknr;
    __le64 flags;

    u8 chunk_tree_uid[16];
    __le64 generation;
    __le64 owner;
    __le32 nritems;
    u8 level;
}

struct btrfs_disk_key {
    __le64 objectid;
    u8 type;
    __le64 offset;
}

struct btrfs_item {
    struct btrfs_disk_key key;
    __le32 offset;
    __le32 size;
}

Uvnitř b-stromu (tj. ve „větvích“ stromu, což je opakem listů na dně stromu) se uzly skládají pouze z klíčů a hlaviček bloků. Klíče říkají, kde hledat položku, kterou chcete, a hlavičky bloků říkají, kde je další uzel nebo list v b-stromě umístěn na disku.

Listy b-stromu obsahují položky, které jsou kombinací klíčů a dat. Podobně jako u Reiserfs jsou data a položky shromážděny s extrémně efektivním využitím místa: Hlavičky položek (tj. struktura item popsaná výše) jsou sloučeny na začátku bloků, zatímco data spojená s každou položkou jsou naskládána dohromady a začínají na konci bloku. Jak je ukázáno na obrázku napravo, hlavičky položek a data rostou směrem k sobě.

Kromě toho, že je to efektivní z hlediska kódu, je toto schéma efektivní i co se týče prostoru a času. Souborové systémy do daného bloku souborového systému obvykle vkládají jenom jeden druh dat – bitové mapy nebo inody nebo záznamy v adresáři. Tím se plýtvá místem na disku, protože nevyužité místo jednoho druhu bloku nelze využít pro jiné účely, a zároveň časem, protože dostat se k jednomu konkrétnímu kousku dat souboru vyžaduje čtení několika různých druhů metadat, přičemž každý druh je uložen v jiném bloku souborového systému. V btrfs jsou položky sloučeny dohromady (nebo vytlačeny do listů) v takovém uspořádání, které optimalizuje jak čas přístupu, tak využití místa na disku. Rozdíl můžete vidět z těchto (velmi schématických a velmi zjednodušených) diagramů. Staré souborové systémy většinou organizují data takto:

Btrfs na druhou stranu vytváří na disku rozvržení, jako je toto:

V obou obrázcích červená barva značí vyplýtvané místo na disku a červená šipka značí posun hlaviček.

Každý druh metadat a dat na souborovém systému – záznam v adresáři, inode, rozšířený atribut, samotná data souboru – se ukládá v konkrétním typu položky. Pokud se vrátíme k definici položky, vidíme, že první prvek je klíč:

struct btrfs_disk_key {
    __le64 objectid;
    u8 type;
    __le64 offset;
}

Začněme polem objectid. Každý objekt v souborovém systému – většinou inode – má unikátní objectid. To je poměrně standardní věc – je to ekvivalent čísel inodů. Btrfs je zajímavý tím, že objectid tvoří nejvýznamnější bity klíče položky – toho, který používáme při vyhledávání položky v b-stromě – a nižší bity jsou různé druhy položek spojené s daným objectid. Výsledkem je, že se všechny informace spojené s daným objectid shromažďují. Pokud alokujete sousedící objectid, pak jsou všechny položky těchto objectid také alokovány blízko u sebe. Pár <objectid, type> automaticky shlukuje související data bez ohledu na jejich skutečný obsah, což je opakem přístupu klasických souborových systémů, které píší samostatné optimalizované alokátory pro každý druh dat souborového systému.

Pole type říká, jaký typ dat je v položce uložen. Je to inode? Záznam v adresáři? Je to rozsah, který říká, kde jsou data souboru na disku? Jsou to samotná data souboru? S kombinací objectid a typu lze v b-stromě najít libovolná data souborového systému.

Měli bychom se v rychlosti podívat na samotnou strukturu uzlů b-stromu a listů. Každý uzel a list je rozsah v b-stromě – uzly jsou rozsahy plné párů <klíč, hlavička bloku> a listy obsahují položky. Rozsáhlá data souboru jsou uložena mimo listy b-stromu, přičemž položka popisující rozsah je uchovávána v samotném listu. (Co je „rozsáhlý“ soubor, je laditelné v závislosti na zátěži.) Každý rozsah popisující část b-stromu má kontrolní součet a počet odkazů, což umožňuje zapisovatelné snapshoty. Každý rozsah také zahrnuje explicitní zpětný odkaz na každý z rozsahů, které na něj ukazují.

Zpětné odkazy dávají btrfs podstatnou výhodu oproti každému jinému souborovému systému ve své třídě, protože s nimi je možné rychle a efektivně migrovat data, inkrementálně souborový systém kontrolovat a opravovat a kontrolovat správnost čítání odkazů během normální práce. Důkazem je, že btrfs již nyní podporuje rychlé, efektivní odstranění zařízení a zmenšení dostupného úložného prostoru souborového systému. Většina ostatních souborových systémů má „zmenšení souborového systému“ na seznamu vlastností, ale obvykle to skončí neefektivní a pomalou implementací, která navíc přijde o několik let později – nebo vůbec. Pro příklad ext3/4 umí souborový systém zmenšit – procházením celého souborového systému a hledáním dat umístěných v oblasti, kde se bude odstraňovat zařízení. To je pomalý, vytěžující a k chybám náchylný proces. ZFS souborový systém stále zmenšit neumí.

Výsledek je krásně obecný a elegantní: Všechno na disku je b-strom, který obsahuje rozsahy položek, pro které jsou počítány odkazy a kontrolní součty, a tyto položky organizuje podle klíčů <objectid, type>. Velká část kódu btrfs se nezajímá o to, co je v položkách uloženo, pouze ví, jak je z b-stromu vyjmout nebo je tam přidat. Optimalizace rozvržení disku je jednoduchá: Alokování věcí s podobnými klíči blízko u sebe.

Btrfs: Politika

Ve stejné době, kdy Chris řešil technický návrh btrfs, řešil také, jak vývoj btrfs financovat jak krátkodobě, tak dlouhodobě. Chris se nedávno přesunul ze SUSE do zvláštní skupiny Linux v Oracle, která zaměstnává několik vysoce postavených vývojářů úložných zařízení v Linuxu, ke kterým patří Martin K. Peterson, Zach Brown a Jens Axboe. Oracle financuje značnou část vývoje Linuxu, něco z toho je zjevně spojeno s databází Oracle (OCFS2, DIF/DIX) a něco méně zjevně (práce na obecné blokové vrstvě, syslety). Tady je, jak to Chris řekl v nedávném interview s Amandou McPherson z Linux Foundation:

Amanda: Proč jsi s tímto projektem začal? A proč ho Oracle podporuje tak výrazně?

Chris: Na Btrfs jsem začal pracovat brzy poté, co jsem nastoupil do Oracle. Měl jsem unikátní příležitost podívat se na věci, které v Linuxu chybí, a měl jsem pocit, že Btrfs je nejlepší způsob, jak je řešit.

Linux je pro Oracle velmi důležitá platforma. Význačně ho používáme v interní práci a má pro nás širokou základnu zákazníků. Chceme, aby byl Linux silný jako operační systém pro datová centra, a inovace v oblasti ukládání je pro Oracle přirozený způsob, jak k tomu přispět.

Jinými slovy Oracle je rád, že může Linux použít jako platformu, a je ochoten investovat do jeho vývoje, i když není přímo spojen s výkonem databáze Oracle. Podívejte se na to takto: Kolik operačních systémů je z velké části psáno a financováno vaší konkurencí? I když je lákavé mít operační systém zcela pod svou kontrolou – jako je tomu u Solarisu – také to znamená platit za většinu vývoje pro takovou platformu. Závěrem je, že Oracle věří, že je v jeho zájmu použít své vlastní experty k tomu, aby Linux zůstal silný.

Po několika měsících programování a diskuzích o návrhu se Zachem Brownem a mnoha dalšími Chris zaslal btrfs k revizím. Od té chvíle je možné sledovat historii btrfs stejně jako historii jakéhokoliv jiného open source projektu z e-mailových konferencí a historie zdrojového kódu. Btrfs je nyní v hlavní řadě jádra a pracují na něm vývojáři z Red Hatu, SUSE, Intelu, IBM, HP, Fujitsu atd. Btrfs je opravdový projekt s otevřeným zdrojovým kódem – nejenom licencí, ale také komunitou.

Btrfs: Stručné srovnání se ZFS

Lidé se často ptají na vztah mezi btrfs a ZFS. Z jednoho úhlu pohledu jsou tyto dva souborové systémy velmi podobné: Oba jsou souborové systémy s kontrolními součty a kopírováním při zápisu s podporou více zařízení a zapisovatelnými snímky. Z jiného úhlu pohledu se podstatně liší: Mezi jinými věcmi architekturou, vývojovým modelem, dospělostí, licencí a hostitelským operačním systémem. Místo odpovídání na jednotlivé otázky proto poskytnu stručnou historii vývoje ZFS a srovnám ji s btrfs u několika klíčových položek.

Když začalo ZFS, se souborovými systémy pro Solaris to také vypadalo bledě. Logující UFS se blížil ke konci provazu, co se týče výkonnosti a velikosti souborového systému. UFS byl tak opožděný, že mnoho zákazníků platilo velké peníze Veritasu, aby místo toho mohli používat VxFS. Solaris potřeboval nový souborový systém a potřeboval ho rychle.

Jeff Bonwick se rozhodl, že problém vyřeší a začal uvnitř Sunu projekt ZFS. Jeho motto bylo stejné jako pro subsystém virtuální paměti – proč by správa a používání disku nemohlo být tak snadná jako u paměti? Centrální datovou strukturou na disku byl slab – kousek disku dělený do bloků stejné velikosti, jako je to u jaderného alokátoru paměti SLAB, který také vytvořil. Místo rozsahů ZFS používá jeden ukazatel na blok pro každý blok, ale každý objekt používá jinou velikost bloku – např. 512 bytů nebo 128 kilobytů podle velikosti objektu. Blokové adresy se překládají pomocí mechanismu podobného virtuální paměti, takže bloky lze přemisťovat bez znalosti vyšších vrstev. Všechna data a metadata souborového systému se ukládají v objektech. A všechny změny souborového systému se popisují jako změny objektů, které se zapisují kopírováním při zápisu.

Ve shrnutí btrfs na disku všechno organizuje do b-stromu rozsahů, který obsahuje položky a data. ZFS na disku všechno organizuje do stromu ukazatelů na bloky s různými velikostmi bloku podle velikosti objektu. Btrfs počítá kontrolní součty a odkazy rozsahů, ZFS počítá kontrolní součty a počty odkazů bloků proměnné velikosti. Oba souborové systémy zapisují změny na disk kopírováním při zápisu – používané rozsahy či bloky nikdy nejsou přepisovány na místě, vždy jsou nejprve zkopírovány někam jinam.

Takže i když je seznam vlastností těchto dvou souborových systémů vcelku podobný, implementace se naprosto různí. Je to trochu jako sbíhavá evoluce vačnatců a placentálních savců – vačnatá myš a placentální myš vypadají zvnějšku téměř identicky, ale jejich implementace se podstatně liší!

Podle mého mínění je základní architektura btrfs mnohem vhodnější pro ukládání než u ZFS. Jedním z velkých problémů přístupu ZFS – „desky“ bloků dané velikosti – je fragmentace. Každý blok může obsahovat objekty pouze jedné velikosti, takže lze snadno skončit například se souborem složeným ze 64k bloků, který potřebuje narůst o jeden blok, ale žádné 64k bloky k dispozici nejsou, i když je souborový systém téměř plný skoro prázdných slabů 512bytových bloků, 4k bloků, 128k bloků atd. Abychom tento problém vyřešili, vyvinuli jsme (my, vývojáři ZFS) způsoby, jak vytvořit velké bloky z malých bloků („spolčení bloků“) a další nepříjemné obcházení problémů. Na naši obranu – v té tobě se b-stromy a rozsahy zdály naprosto nekompatibilní s kopírováním při zápisu a podoba s virtuální pamětí nám dobře sloužila v mnoha dalších aspektech.

V kontrastu s tím přístup položek v b-stromě extrémně efektivně využívá místo a je flexibilní. Defragmentace je nepřetržitá – opakované balení položek je efektivně součástí normální kódové cesty, která připravuje zápis rozsahů na disk. Počítání kontrolních součtů, čítání odkazů a provádění dalších nejrůznějších déletrvajících prací na úrovni rozsahů redukuje režii a umožňuje nové vlastnosti (jako je rychlé reverzní mapování z rozsahu na všechno, co se na něj odkazuje).

Nyní několik osobních předpovědí (založených čistě na veřejných informacích – nemám žádné zákulisní informace). Btrfs bude výchozím souborovým systémem pro Linux během dvou let. Btrfs jako projekt nebude (a v tomto bodě ani nemůže být) Oraclem zrušen. Pokud budou vyřešeny všechny záležitosti okolo duševního vlastnictví (velké pokud), ZFS bude portován na Linux, ale oproti btrfs bude mít zastoupení jenom pár procent. Vraťte se sem za dva roky a uvidíte, jestli jsem se v něčem trefila!

Btrfs: Co dál?

Btrfs míří k verzi 1.0 po více než dvou letech od prvního oznámení. To je mnohem rychleji, než mnoho veteránů souborových systémů – včetně mě – čekalo, obzvláště vzhledem k tomu, že po většinu toho času měl btrfs pouze jednoho vývojáře pracujícího na plný úvazek. Btrfs není připraven pro produkční nasazení – tj. pro ukládání a vybavování dat, jejichž ztráta by vás naštvala – ale je připraven pro široké testování – například na vašem laptopu, který se denně zálohuje, nebo na experimentálním netbooku, který stejně přeinstalováváte každých pár týdnů.

Mějte na paměti, že se nedávno měnil formát btrfs na disku: Commit, který přišel těsně po vydání 2.6.30, mění formát na disku způsobem, který je nekompatibilní se staršími jádry. Pokud vytvoříte souborový systém btrfs s jádrem a nástroji pro 2.6.30 nebo starší a nabootujete nové jádro s novým formátem, nebudete schopni souborový systém nadále se starším jádrem používat. Linus Torvalds na to přišel složitým způsobem. Pokud se to nicméně stane vám, nepanikařte – na btrfs wiki lze najít záchranné obrazy a další užitečné informace.

       

Komentáře

[David Watzke]

Díky za článek, Btrfs mě zajímá. Mám verzi 0.18 na 4 oddílech (celkem 94,4 GB) a zatím je to v pohodě Až mi něco překazí uptime, tak tam hodím nový jádro a aktualizuju je...

[David Watzke]

No tak tohle je slušná shoda okolností, zrovna jsem jeden btrfs oddíl asi zrušil Nějak jsem pozapomněl na to, že by ho člověk neměl moc naplňovat... Zatím je připojenej a nemůžu k datům, ale pochybuju, že to půjde opravit. Už jsem se s těmi daty rozloučil. Ještě že mám rychlej download

[David Watzke]

Tak nic, funguje to zas po btrfsck

[Petr Ježek]

Pro pochopení: "The filesystem checking utility is a crucial tool, but it can be a major bottleneck in getting systems back online after something has gone wrong. Btrfs aims to be tolerant of invalid metadata, and will avoid using metadata it determines to be incorrect. The disk format allows Btrfs to deal with most corruptions at run time, without crashing the system and without requiring offline filesystem checking."

[thingie]

b-strom je tak nepřátelský termín. Zatím jsem vždycky viděl B strom nebo B+ strom v případě variant a jim podobných.

[eax]

ma v sucastnosti btrfs vyznam pre oracle ? po tom co kupili SUN a maju solaris a zfs ?

[trekker.dk]

Podle článku jsou věci, které ZFS neumí

[Robert Krátký]

Především ZFS "neumí" Linux - a Oracle má dosti významný podíl instalací na Linuxu.

[thingie]

To by se dalo vyřešit i snáz než vývojem zcela nového FS

[Robert Krátký]

a) Btrfs začal o dost dříve než Oracle koupil Sun.

b) Jak?

[eax]

skor by ma zaujimalo ze ci oracle este stale ma zaujem btrfs vyvijat, alebo je to uz len na OS komunite. tam kde je oracle nasadeny na linuxoch ho zrejme preinstalovavat kvoli btrfs nebudu... no a na nove instalacie nepreferuju teraz solaris ?

[thingie]

Na FreeBSD ZFS mají, sice asi ne v dvakrát úžasném stavu, ale jo. Proč by Linux nemohl.

[Robert Krátký]

Jednak kvůli licenci, ale také asi proto, že btrfs považují za lepší návrh. Viz článek - třeba se ty předpovědi naplní.

[thingie]

Licence -- aneb když nemáte důvod, tak už jo. Klasika, no. (Ne že by mě ZFS nějak zajímal, ale…)

[Robert Krátký]

Licence je stejně dobrý důvod jako každý jiný. Až se Sun/Oracle umoudří s licencí OpenSolarisu, bude mít cenu diskutovat o technickém meritu těch věcí. Do té doby je to zbytečné, protože by to v Linuxu prostě nešlo distribuovat.

[Milan Jurik]

Až se Sun/Oracle umoudří s licencí OpenSolarisu

Eh? To slovo "umoudri" je opravdu nevhodne zvolene. Co je spatne na licenci, ktera zarucuje svobodne sireni, vcetne patentove ochrany uzivatelu a take soudni ochrany tvurce kodu? Proc se ma umoudrovat Sun, kdyz je to GPL, ktera je limitem a odmita pripustit, ze nejen uzivatel, ale i tvurce kodu ma pravo na ochranu pri zachovani otevrenosti kodu? Navic, jak uz bylo nekolikrat receno, kdyby existoval skutecny zajem ze strany Linuxu ZFS podporovat, tak minimalne read-only implementace od Sunu pod GPL existuje (ano, limitovana, v Grubu). Jenze pri prislusne diskuzi v LKML nasledovaly opet netechnicke argumenty.

[trekker.dk]

Jenze pri prislusne diskuzi v LKML nasledovaly opet netechnicke argumenty.

Kecy v kleci. V příslušné diskuzi šlo hlavně o to, jestli má cenu takovou podporu dělat. A navíc - což také pro jistotu nezmiňuješ - výsledkem té diskuze bylo, ať si to ten dotyčný klidně vyrobí, pokud chce.

[Milan Jurik]

A ta cast o nepodporeni moznosti zahrnuti kvuli obavam z patentu Sunu? Ne, ze by za touhle casti debaty stal LT, ale byla podstatnou casti debaty. Jasne, byly to kecy v kleci.

Shrnuto: ZFS ma plne dokumentovany on-disk format (a to nejen zdrojovym kodem). Existuje vzorova otevrena implementace. Jenze nikdo nema business model pro to, aby investoval do implementace ZFS do Linuxu. Sun, tak jako kazda jina firma prispivajici pro Linuxu, potrebuje business duvod, neni to charita. A ten v pripade dual-licencovani ZFS a udrzovani Sunem nema smysl, Linux predstavuje minoritni platformu z hlediska supportu pro Sun, neni to RH, Novell ci IBM nebo tvurce embedded systemu. Tak jako licencovani celeho Solarisu pod GPL licenci postrada smysl, protoze by se pak z toho stal nedistribuovatelny kus kodu a i kdyby slo vyresit problemy s uzavrenymi castmi kodu, tak by to znamenalo hodit pres palubu vsechny tvurce uzavrenych ovladacu pro enterprise systemy a vsechny dosavadni takove ovladace. Nemluve o chybejici patentove ochrane uzivatelu, ktera je v GPLv2 diskutabilni.

Ja nevytykam Linuxu, ze neimplementuje ZFS, je to volba daneho systemu. Ale ty stesky, ze bakany Sun Linuxu ZFS neda, jsou uz unavujici. Je to volba Linuxu a jeho tvurcu, ne Sunu.

[trekker.dk]

A ta cast o nepodporeni moznosti zahrnuti kvuli obavam z patentu Sunu?

Jistě, každou chvíli se někde objeví obvinění, že Linux porušuje něčí patenty, ale obavy z patentů Sunu nejsou dobrý důvod pro nezačlenění fs.

Ne, ze by za touhle casti debaty stal LT, ale byla podstatnou casti debaty. Jasne, byly to kecy v kleci.

Ty kecy v kleci se samozřejmě týkaly tvého výlevu.

Sun, tak jako kazda jina firma prispivajici pro Linuxu, potrebuje business duvod, neni to charita. A ten v pripade dual-licencovani ZFS a udrzovani Sunem nema smysl

Samozřejmě, ZFS je jedna z mála věcí, kde Solaris zatím v něčem Linux aspoň trochu předčí, tak ho přece nebudou duálně licencovat.

[Vskutečnosti Saýc]

Solaris predci linux ve spouste veci (a ve spouste veci predci zase linux solaris). O to vetsi skoda je to s tim Oraclem, pac ted se do solarisu nikomu nechce kdyz dost mozna nema budoucnost.

[Milan Jurik]

Proc by Solaris nemel budoucnost? LarryE dal snad dostatecne jasne najevo, ze v Sunu jej zajimaji nejvice dve veci - Java a Solaris. A ne kazdy je jako Sun, aby za neco zaplatil par miliard dolaru a pak to vyhodil oknem...

[Ivan]

JJ, byvaly doby kdy byl Solaris hlavni vyvojova platforma pro Oracle. Novy verze, patche vychazely nejdrive pro Solaris a pak pro ostatvni platformy. Postupem casu ale zacal Sparc zaostavat za konkurenci - pomer cena/vykon byl mnohem horsi nez u Linuxu na Intelu. To je taky duvod proc se Oracle preorientoval na Linux.

[Milan Jurik]

Tohle je dost sporne tvrzeni Asi hodne zalezi na typu nasazeni (a to Oracle DB by potrebovala poladit praci na SMP systemech mnohem lepe). Nemluve o tom, ze i dnes je Solaris nejvice nasazenym systemem pro Oracle software, aspon podle Oracle

[Milan Jurik]

Jistě, každou chvíli se někde objeví obvinění, že Linux porušuje něčí patenty, ale obavy z patentů Sunu nejsou dobrý důvod pro nezačlenění fs.

Zneuzil Sun svych patentu k utoku, ci je uziva jen na obranu v patentovych sporech? Nedeklaroval Sun verejne, ze nebude danou implementaci blokovat patenty? Pritom Linuxu nevadi prijimat kod od firem, ktere patentove utoky vedou.

Ty kecy v kleci se samozřejmě týkaly tvého výlevu.

A take toho tveho. Nebo zacneme rozebirat jednotlive prispevky do te diskuze a hledat, ktere casti jsou v ni skutecne technicke?

Samozřejmě, ZFS je jedna z mála věcí, kde Solaris zatím v něčem Linux aspoň trochu předčí, tak ho přece nebudou duálně licencovat.

Opet, jaky business reason by mel mit Sun na to, aby dedikoval zdroje na takovou praci (treba udrzovani obou vetvi nebot by zahy doslo k forku u GPL verze)? Jaky prinos by to melo pro Sun? V Linuxu zjevne o to stejne nikdo nema jasny zajem, kdyz se ani o naznak read-only verze nepokousi.

Nejen ZFS je Solaris ziv, ac to Cox a Morton jeden cas usilovne deklarovali. Posledni dobou nejak mlci...

Jinak jsem zvedav, jak btrfs dopadne. Dava nadeji, ze na Linuxu bude opravdu moderni fs (a diky formatu i mozna s velmi dobrym chovanim) a podle vseho by mohl dopadnout lepe nez dtrace-like SystemTap akce.

[trekker.dk]

Opet, jaky business reason by mel mit Sun na to, aby dedikoval zdroje na takovou praci (treba udrzovani obou vetvi nebot by zahy doslo k forku u GPL verze)?

I kdyby došlo k forku, stále tu nevidím důvod, proč by Sun měl udržovat obě větve. Není nic jednoduššího než "Forkli jste si to? Spravujte si to sami." A když na to tak narážíme - dvě větve by stejně vzniknout musely, protože rozhraní pro ovladače v Solarisu a v Linuxu určitě kompatibilní nebude.

Nejen ZFS je Solaris ziv, ac to Cox a Morton jeden cas usilovne deklarovali. Posledni dobou nejak mlci...

Možná se drží zásady, že do mrtvol se nekope.

V Linuxu zjevne o to stejne nikdo nema jasny zajem, kdyz se ani o naznak read-only verze nepokousi.

Co si budeme povídat, využití omezené read-only implementace je... omezené. Není divu, že si spousta lidí položí otázku, proč se s tím dělat.

[Milan Jurik]

I kdyby došlo k forku, stále tu nevidím důvod, proč by Sun měl udržovat obě větve.

Protoze ZFS se stale vyviji, takze by musela byt neustale vydavana i GPL verze (at uz by ji syncoval pak kdokoliv). A kde je ekonomicka logika v uvolnovani kodu pod nejakou licenci, pokud dany kod neni dale tvurcem vyuzivan? Jediny ekonomicky duvod pro Sun, prosim.

Možná se drží zásady, že do mrtvol se nekope.

Tyhle hlasky slychavam uz mnoho let. A ne a ne umrit. A ne a ne padnout prijmove pod prijem RH a Novellu dohromady, ac je cena za support nizsi. Cim to, safra, bude?

Co si budeme povídat, využití omezené read-only implementace je... omezené.

Kdyz uz ne jako zaklad pro plnou podporau, tak ze by moznost migrace dat ze Solarisu na Linux (a ne opacne)? Vyhodne pro Linuxove distributory, alespon teoreticky. Jenze ti se zabyvaji migracemi ze Solarisu 8 (a pak usilovne marketinguji, jak bylo dosazeno neuveritelneho zrychleni proti 10 let starym instalacim)

[m;)]

To je len prechodny stav, nie je jednoduche integrovat tak velky kus kodu z ineho OS. V 7.2 na amd64 uz netreba prakticky nic ladit a v novom 8.0 (a 7.3) bude dalsia varka zlepseni a oprav. Btw od 8.0 uz nie je ZFS na FreeBSD povazovany za experimentalny.

[Jiri Bajer]

Akvizice muze byt motivovana bud sloucenim oblasti podnikani, nebo eliminaci konkurence. Pri slucovani oblasti podnikani se nektere oblasti obou firem prekryvaji a tam se bud vybere a vyuzije z obou svetu to lepsi (spise teoreticka varianta), nebo se jedna z variant proste posle ke dnu (typicky ne ta lepsi a vyspelejsi, ale ta, ktera ma politicky zdatnejsi management).

Podle me tahle akvizice je spis o slucovani a myslim si, ze krome hardware a Javy budou mit v prekryvajciich se oblastech silnejsi slovo manazeri z Oracle. Navic naklady na vyvoj reseni s obrovskou a aktivne prispivajici komunitou jsou mnohem mensi, nez u reseni, kde se komunita sotva zacala budovat a kde se resi jak to vubec nainstalovat, nakonfigurovat a vybabrat se z detskych neduhu, ktere u rozsirenejsich reseni uz byly v prubehu casu poreseny.

Obrovska vyhoda muze spocivat v prelicencovani Solarisu na GPL a postupnem slucovani zajimavych kousku kodu s Linuxem - je to mnohem snazsi proces, nez takhle slucovat fyzicke vyrobky. Na druhou stranu jakekoliv slucovani firem znamena odliv puvodnich zamestnancu a tudiz i know-how k zajimavym technologiim, ktere by za slouceni staly. Aby vysledna firma byla rozumne efektivni, budou se muset postupne slucovat i firemni procesy, zpusob odmenovani a benefity a hlavne firemni hodnoty a kultura. To je dalsi kamen urazu pro lidi, kterym vyhovovala atmosfera v kupovane firme a nekousnou radikalni zmenu situace. To bohuzel jeste zmensuje sanci, ze Linux z akvizice bude nejak vyznamne tezit.

Navic cely tehnle proces ale potrva nekolik let, protoze pri podpisu smlouvy o slucovani se typicky kupujici zarucuje za to, ze po urcitou dobu (treba rok nebo dva) nebude v koupene firme propoustet a rusit projekty. Proto bych moc neresil, ktery ze zminovanych filesystemu/volume manageru prezije - asi tu nejakou dobu budou oba, budou se postupne priblizovat a casem se do jednoho z nich prestane investovat. Tehdy se ukaze, jestli komunita bude mit zajem ho udrzovat...

[=^..^= AmigaPower®]

S tim rozvrženim dat je to "znovuobjevení ameriky", OFS uměl využít místo do posledního bitu už v roce 1984, bohužel vývoj (FFS) skončil někde kolem roku 1991. Nicméně s přístupovými časy to byla tragédie, protože data nebyla nijak sortována, v tomhle vidim asi nejvetší přínos Btrfs...

[progdan]

Btrfs je vyborna vec, ackoli uz sem jednou narazil. Z nejakeho duvodu se zhroutil a zadny ze "zachrannych" nastroju nefungoval - respektive fungoval, ale vzdy skoncil segfaultem. Nakonec mi nezbylo nez partition znovu naformatovat. Ale dal sem mu druhou sanci a zda se, ze se zatim drzi skvele.

[disorder]

například na vašem laptopu, který se denně zálohuje

aaa-hahahahahahahaha

[thingie]

To klidně může bejt ten případ, pokud na tom člověk něco vyvíjí a večer to pushne do gitovýho repa někde jinde. Ono to zase není tak automaticky nereálný, víme?

[disorder]

pokial by slo len o to, tak si mozes naformatovat ako subor a mountnut.

ale koho by potom zahrial ten dobry pocit, ze sa musis srat s obnovou v najnevhodnejsej chvili...

[thingie]

Jako tradičně nějak nechápu, co se snažíš říct. Je spousta lidí, kteří rádi zkusí btrfs na živém systému v nějakém přibližně reálném nasazení, což může být třeba právě nějaký vývoj, kde to zálohování víceméně obstará nějaký git, který člověk používá tak jako tak, takže to nepřidělá moc starostí navíc…

[disorder]

nie, naozaj to nepochopim. rovnako ako nepochopim ludi, co musia kazdy tyzden skusat inu distribuciu.

a pokial by sa stratil len git repozitar, tak to nemusim davat na samostatnu particiu, ale staci na to obycajny subor. preco tam pchat rovno cely home a potom nadavat ked sa to zjebe?

[thingie]

No, někdo to otestovat musí. A mít na tom celý systém, nebo aspoň home, je více testování, než mít na tom data jediné aplikace. Při porušení takového fs se pak samozřejmě přijde o celý systém, ale to je jen sbírka balíčků a nějaké konfigurace, což se (u rozumné distribuce) obnoví nějakým kickstartem nebo tak při takřka úplně automatické instalaci, takže to není třeba zálohovat. A samozřejmě to děláme tehdy, pokud s něčím takovým počítáme, a když nám to spadne, je to řízení osudu, objevená chyba, a ne jenom příležitost nadávat (těch se najde bohatě dost při libovolné činnosti).

(Ono by k tomu chápání nebylo třeba zase tak *moc*.)

[disorder]

niekto kto podstupi take riziko bud nevie co robi alebo ma prilis vela casu, a najlepsi argument je to, ze mame zalohovane laptopy xD

[thingie]

O tom fs nikdy nepůjde říct, že je stabilní, dokud za sebou nebude mít spousty hodin skutečného běhu. A co se týče toho zálohování, tak to jsem popsal už na začátku vlákna… (Jo, to chápání, no.)

[disorder]

ano, s tym chapanim ti to ide pomalsie: clanok naznacuje, ze moj laptop nevyzaduje produkcnu kvalitu a to je teda riadny bullshit.

druha vec je, ze vraj mam denne zalohovany laptop:

1. nemam

2. aj keby mam, tak ak by sa to nahodou zrubalo pocas prace, to by bolo tiez velmi pekne

[thingie]

Asi by to bylo hezký, ale smůla je, že konkrétně ty nikoho nezajímáš, a ten článek (byť promlouvá ke čtenáři ve druhé osobě) ani není o tobě ani o tvém laptopu (sorry), článek pouze nabízí výčet možných scénářů vhodných pro testování… (Ono to chápání fakt není tak těžké.)

[Leoš Literák]

Ja pochopil clanek tak, ze se mluvi o Linusove notasu, ne o tvem

[m;)]

ja to zasa vnimam asi podobne ako disorder. vacsina ludi nema denne zalohovany laptop a ked filesystem odide je to urcite minimalne kopec zbytocnej prace a v horsom pripade aj stratenych dat. filesystem musi nutne byt jedna z najstabilnejsich casti systemu.

[stativ]

Ta holka je ďábel…

[Václav HFechs Švirga]

Hehe, souhlas!

[Nicky726]

Dík za zajímavý článek.

[geebranz]

It gets a little confusing

polebarnscheyennewy.com