Názory k článku
Canonical pracuje na podpoře ZFS pro kořenový oddíl
-
Ty licence jsou svobodné. Třetí strana (Canonical) se může, na svoje riziko, pokusit obě díla sloučit. Možná mají právní analýzu, že de iure nejsou slučitelné, ale de facto slučitelné jsou (tj. teoreticky mohou nastat kolizní situace, ale v praxi se dají ošetřit, aby nenastaly). Takové názory se už objevily. Možná se rozhodli se, že se to pokusí ustát i právně (kdyby to někdo zažaloval).
Takové konstruktivní snaze bych tleskal, kolem volných licencí se hodně mluví, ale k jejich opravdovému uplatnění (před soudy) je katastroficky málo pramenů.
Rizikem pro Linux by naopak bylo, kdyby na základě této zkušenosti začaly vznikat silné forky Linuxu.
-
Našel jsem k tomu toto, je to z 2016 - takže to vypadá, že s tou myšlenkou pracují už dlouho: http://blog.dustinkirkland.com/2016/02/zfs-licensing-and-linux.html.
Mně ten "legal problem" přijde dost žabomyší, protože ani jedna licence ve skutečnosti nikomu nebrání ZFS v Linuxu užívat, problém je jen s distribucí zrojáků. Obě licence tedy směřují ke stejnému užitku, jejich nekompatibilita je víceméně formální.
Užitek ze ZFS (i z Linuxu) vzniká až po kompilaci a spuštění, samotný zdrojový kód (bez kompilace) nikomu nic nepřinese. Pokud tedy říkáme, že kompilace i užití ZFS je lege artis, domnívám se že úvahou a maiori ad minus (tj. pokud musím strpět důsledek, musím strpět i předpoklad) nutně dojdeme k tomu, že sloučenou distribucí dochází ještě k menšímu užití (ne-li nulovému), než je výslovně povolené. Zajímalo by mě, jak by se v takovém případě počítala škoda? (https://wiki.iurium.cz/w/Interpretace_pr%C3%A1va#Argumenty_logick.C3.A9ho_v.C3.BDkladu_pr.C3.A1va)
-
Ondra Satai NekolaZlatý podporovatelTo je hezka hypoteza. Ale dokud jsou na druhe strane licencni pravnici Oracle, tak bych rozhodne nemel nerv ji testovat.
-
Na druhou stranu, jak některé distribuce Linuxu, tak třeba FreeBSD ukazují, že jak binární distribuce, tak i kompilace ze zdrojů mohou existovat i v kombinaci různých licencí.
Linux vyžaduje, aby zdrojové kódy ZFS byly přelicencovány pod GPL a nechce připustit, že by v distribučním zdrojovém balíku mohly koexistovat kódy s odlišnými licencemi. Přitom by stačilo před kompilací vyžadovat odsouhlasení jednotlivých licencí a podle toho nabízet / nenabízet jednotlivé moduly.
-
V Gentoo som mal / na zfs už pred mnohými rokmi, ale vtedy som musel mať /boot na osobitnej partícii. Potom ma začali srať, pretože bez initramfs systém nechcel nabootovať a s tým sa mi nechcelo babrať. Podporu zfs som mal priamo v kerneli. Samozrejme na licenčnú politiku som nehľadel, inak by to bez initramfs nešlo.
-
Snaze Canonicalu tleskám! Pak už je jen krůček od implementace boot environmentů. Pokud tohle zavedou, okamžitě přecházím na ubuntu.
Představa, že si vytvořím boot environment, do kterého přebootuju, můžu ho komplet roztřískat a příště nabootuju do původního environmentu a ten rozbitý zlikviduju, a to vše v linuxu a ne v Solarisu/BSD, je úžasná. Žádné obavy z nepovedeného updatu...
-
Těžko říct, jestli je to zrovna vhodný usecase. ZFS je hodně náročný a jeho přínosy podle mě leží někde dál.
Pokud "roztřískáváte" systém na pokusy, pak bych spíš využil nějakou virtualizaci a snapshoty na úrovni virtuálního disku (tj. není nutné mít boot environment). Pokud je to myšleno, jen pro případ problému, pak mi přijde zase jednodušší mít úplně obyčejnou zálohu. Tar xf sice bude trvat o pár minut déle, ale to se Vám přihodí jen jednou za čas. ZFS Vám sežere kus výkonu i paměti, a to trvale.
-
Na Solarisu a potažmo FreeBSD používám skoro denně.
Zálohování tarem a případná obnova rozbitého systému vám přijde jednodušší? V případě virtuálního prostředí musíte nejdřív živý systém přenést do virtualizace. V případě beadm je postup následující:
beadm create <test_be>; beadm activate <test_be>
reboot
ted otestuju a rozbiju
beadm activate <old_be>
reboot
beadm destroy <broken_be>?Kdokoliv z mého okolí, kdo kdy přičichl ke kombinaci ZFS root/beadm, tohle považuje za naprostou killer feature.
Vy opravdu před každým updatem systému děláte zálohu tarem, abyste se mohl vrátit zpět?
-
Zrovna na FreeBSD mi to nepřijde moc nutné. Celý systém jsou balíky base.txz a kernel.txz (evt. lib32.txz). Takže jediné, co potřebuji zazálohovat je /etc, /var, /usr/local a /usr/home. To proběhne rychle. Ve skutečnosti není ani moc nutné zálohovat /var před updatem, tam se většinou nic nerozsype, takže na pokrytí rizik stačí pravidelné zálohy.
Daň v podobě RAM a CPU ve prospěch ZFS mi přijde příliš vysoká na to, abych ocenil přínos na riziko rozsypání update - ostatně ani se to často neděje, že by update nebo upgrade dělal problémy.
90 % instalací stejně běží ve virtualizaci, takže je jednodušší na ESXi udělat snapshot celého vmdk. ESXi má jednu režii pro X virtuálních guestů, zatímco kdybych v každém z nich měl mít ZFS, sežere to velký kus RAM. Nebo bych musel vypnout ARC, ale v tu chvíli je ZFS žalostně nevýkonné oproti tradičnímu filesystému.
-
KateStříbrný podporovatel
Co mi brání udělat tohle s Linuxem na btrfs? Rozbiju snapshot, nabootuju starší funkční.
-
ZFS je filesystém a volume manager dohromady. Má spoustu velmi pokročilých funkcí. Je jednoduché do něj přidávat nové disky. Nemusíte řešit rozdělení na parcely - ZFS si vezme celé disky a na jednotlivé volumes přiděluje místo podle potřeby.
U tradičního filesystému musíte dopředu rozhodnout, jestli vyrobíte nějaký RAID a jeho geometrie je pak neměnná. U ZFS se určí jen míra redundance (Z1 - Z3 - odolnost proti výpadku jednoho až tří disků), o zbytek se ZFS postará automaticky. Uhlídá si to i při přidání dalšího disku.
Na jednotlivých volumes lze nastavit spousta parametrů - např. komprese bloků (lz4, gzip, lzjb, zle), deduplikace (identické bloky jsou zapsány jen jednou, ale mohou být referencovány vícekrát), nebo naopak počet kopií bloků (tentýž blok je zapsán na dvě různá místa kvůli bezpečí), checksumming (sha256, salted sha512, salted skein, ...). Nastavitelná je na každém volume (v rámci jednoho ZFS) velikost bloku - to je užitečné na ladění výkonu pro konkrétní aplikace. Součástí ZFS jsou i ZVOL, tedy jakási "emulace" blokového zařízení (ideální např. pro export iSCSI).
A to, o čem se tu bavíme je možnost snapshotování filesystému a návrat ke staršímu snapshotu. Hezkou podfunkcí je to, že se celý snapshot dá vyexportovat (např. do souboru) a natáhnout někam jinam.
ZFS má prostě hafo funkcí, je to špičkový filesystém. Jediná moje výhrada je, že ne všude je nutný, protože sežere poměrně dost paměti.
-
Ano, ZFS ma spoustu skvelych funkci. Jen jeho pametova nenazranost je fakt velka. Trosku me mrzi, ze treba u FreeNAS a NAS4Free uz to bude brzo jediny mozny FS. FreeNAS to udelal uz pred par lety a proto jsem utekl k NAS4Free. Ti to ted taky planuji. Novy FS, ktery pujde vytvorit je pouze ZFS, stare (UFS) to bude umet uz jen udrzovat.
Ja tyhle distribuce pouzivam pro zalohovani, potrebuju jen NFS, nekde CIFS. Rad jsem to daval na starsi zelezo (nebo HP Microserver) a nastrkal do toho par disku. Takovemu zalohovadlu by stacilo 2GB RAM, se ZFS zacinate o dost vyse.
-
Pro NFS a CIFS by to nemusel být úplně velký problém. Nastavil bych menší ARC (třeba 1G, možná méně), vypnul cachování streamových dat, snížil cache na vdev.
Kdyby to nepomohlo, tak bych si ještě pohrál s recordsize (dát si pozor na alignment s fyzickým blokem, pokud máte disky s 4k nebo 8k nativními bloky), můžete vypnout checksumming a snížit objem metadat (=most vs. =all).
Tím se výkon přiblíží tradičními filesystému.
(Alternativou ke snížení ARC je ještě nechat ji vysokou, ale nastavit, aby udržoval vždy aspoň 1G v RAM volný, aby nenastal tlak na swapování - tuto funkci ZFS na FBSD má taky a je docela šikovná právě na to, aby se zachovalo maximum ARC a vyhnulo se swapu).
-
Ovsem ZFS neni jedinej system co tohle umi, dalsi je treba narozdil od ZFS na Linuxu nativni btrfs, kterej umi vicemene to samy jako ZFS s mensimi naroky na HW. Oba filesystemy samozrejme zaroven maj negativa o proti tradicnim filesystemum v podobe nizsi efektivity (pri kazdym zapisu do jednoho sektoru je nutne zapsat do nekolika dalsich sektoru k vuli zmene checksumu, coz se castecne resi cachovanim zapisu).
