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í
×
včera 20:22 | Nová verze

Po dvou měsících vývoje od vydání verze 6.0.0 byla oficiálně vydána nová verze 6.1.0 správce digitálních fotografií a nově i videí digiKam (digiKam Software Collection, Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení. Vývojáři zdůrazňují nové API pro rozšíření DPlugins nahrazující KIPI. Ke stažení je také balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo ke spuštění a spustit.

Ladislav Hagara | Komentářů: 0
včera 19:55 | Nová verze

Byla vydána verze 1.16.0, tj. první stabilní verze nové řady 1.16, multiplatformního multimediálního frameworku GStreamer (Wikipedie). Z novinek lze zdůraznit vylepšení podpory WebRTC nebo AV1. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
včera 11:55 | Nová verze

Po více než 3 letech od vydání verze 1.3.0 byla vydána nová stabilní verze 1.4 multimediálního přehrávače MPlayer (Wikipedie). Nejnovější verze přináší kompatibilitu s verzí 4.1 a také s aktuální vývojovou verzí multiplatformní multimediální knihovny FFmpeg (Wikipedie).

Ladislav Hagara | Komentářů: 12
18.4. 23:55 | Komunita

Mozilla oznámila, že projekt Things byl přejmenován na WebThings. Nové jméno by mělo zdůraznit, že se nejedná pouze o projekt IoT (Internet věcí), ale o WoT (Web věcí). Současně byla vydána WebThings Gateway (GitHub) ve verzi 0.8 pro Raspberry Pi.

Ladislav Hagara | Komentářů: 0
18.4. 21:11 | Nová verze

Byl vydán balík KDE Aplikace ve verzi 19.04. Shrnuje práce za poslední čtyři měsíce: opravy chyb, mj. ve správci souborů Dolphin, prohlížeči dokumentů (nejen PDF) Okular nebo prohlížeči obrázků Gwenview – tyto dostaly např. lepší podporu dotykových obrazovek. Významného přepracování se dočkal editor videa Kdenlive.

Fluttershy, yay! | Komentářů: 3
18.4. 16:22 | Nová verze

Byla vydána verze 19.04 linuxové distribuce Ubuntu a oficiálních odnoží Ubuntu Budgie, Kubuntu, Lubuntu, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio a Xubuntu. Kódový název Ubuntu 19.04 je Disco Dingo. Přehled novinek a odkazy ke stažení v poznámkách k vydání. Ubuntu 19.04 bude podporováno 9 měsíců, tj. do ledna 2020.

Ladislav Hagara | Komentářů: 8
18.4. 09:55 | Nová verze

Byla vydána verze 8.0 sady aplikací pro SSH komunikaci OpenSSH. Řešena je bezpečnostní chyba CVE-2019-6111 v scp. Přidána byla experimentální podpora výměny klíčů, která je odolná vůči kvantovým počítačům (Streamlined NTRU Prime 4591^761 a X25519). Výchozí délka nově generovaných RSA klíčů je 3072 bitů.

Ladislav Hagara | Komentářů: 0
17.4. 22:44 | Komunita

Zend Framework, open source objektově orientovaný webový aplikační framework implementovaný v PHP, byl předán neziskovému technologickému konsorciu Linux Foundation. Framework se pod novým názvem Laminas v průběhu několika měsíců stane oficiálním projektem konsorcia.

Ladislav Hagara | Komentářů: 4
17.4. 22:00 | Komunita

Gentoo Foundation a společnost Nitrokey společně oznámily, že všichni vývojáři linuxové distribuce Gentoo budou vybaveni kryptografickým tokenem Nitrokey Pro 2 (pdf). Vývojáři se mají zaregistrovat s emailovou adresou @gentoo.org.

Ladislav Hagara | Komentářů: 0
17.4. 20:55 | Zajímavý software

Článek na PIXLS.US představuje svobodný program pro zpracování astronomických fotografií s názvem Siril (GitLab) a uvádí postup, jak v Siril vytvořit hezký snímek noční oblohy.

Ladislav Hagara | Komentářů: 0
Používáte headset pro virtuální realitu?
 (1%)
 (3%)
 (1%)
 (20%)
 (0%)
 (74%)
Celkem 210 hlasů
 Komentářů: 12, poslední 18.4. 01:19
Rozcestník

OpenSolaris - 3 (ZFS)

17. 3. 2009 | Jakub Jirků | Recenze | 7804×

Jedním z největších trháků OpenSolarisu (a vlastností nejvíc propíranou) je souborový systém ZFS a právě o něm bude třetí díl seriálu. Ale nebojte se, zabrousíme i kousek stranou k NFS a CIFS.

Co je ZFS?

Se ZFS, tedy něcoodZ file system je to trochu složitější. To Z v názvu mělo původně znamenat zettabyte, kde zetta je (nepříliš známý) Si prefix pro 10^21, ale to není úplně maximální kapacita ZFS, a krom toho je to dost ošklivé slovo, takže od něj tvůrci později ustoupili a teď se říká, že ZFS prostě proto, že jde o "last word in filesystems" (poslední slovo v oblasti souborových systémů).

ZFS vzniklo tak, že skupinka techniků vedená Jeffem Bonwickem dostala za úkol vytvořit něco nového, bez zpětné kompatibility nejen co se týká API, ale i co se týká samotného přístupu k věci. Podle jejich slov bylo jejich hlavním cílem zbavit se problémů s volume managery a jejich interakce se souborovými systémy, zbavit se nástrojů jako fsck, vylepšit bezpečnost dat, ušetřit práci správcům, a vůbec udělat souborový systém trochu chytřejší, než bylo v kraji zvykem. Nakolik se jim to podařilo, uvidíme podrobně za chvíli, ale pro teď můžu prozradit, že ZFS skutečně je kombinace volume manageru a souborového systému, že je vždycky konzistentní a nepotřebuje fsck, dělá kontrolní součty kdečeho a umí opravovat chyby v datech a spoustu dalších věcí. ZFS nicméně není sdílený ani clusterový souborový systém.

Rampant Layering Violation?

Připadá vám myšlenka kombinovat souborový systém a volume manager šílená? Adrewovi Mortonovi, který stojí za slovním spojením v nadpisu, taková zřejmě připadala. Ono to ale mění víc věcí, než by se mohlo na první pohled zdát, a celé se to váže k věci, které se v marketingových materiálech říká "pooled storage model".

Tedy, místo toho, abyste jednotlivé kusy úložišť (lhostejno jestli levných SATA disků nebo logických jednotek ze síťového pole v ceně menší vilky) přiřadili nějakým svazkům nebo souborovým systémům, všechny je vložíte do jednoho poolu, který je přístupný všem souborovým systémum, a ty mají všechny k dispozici plnou kapacitu a rychlost všech jednotek. Na ukázku si půjčím rpool své stanice:

jakub@ferda:~/zfs$ zfs list
NAME                       USED  AVAIL  REFER  MOUNTPOINT
rpool                     12.7G   138G  74.5K  /rpool
rpool/ROOT                3.37G   138G    18K  legacy
rpool/ROOT/opensolaris-1  3.37G   138G  3.29G  /
rpool/dump                1023M   138G  1023M  -
rpool/export              6.28G   138G    21K  /export
rpool/export/home         3.55G   138G    19K  /export/home
rpool/export/home/jakub   3.55G   138G  2.73G  /export/home/jakub
rpool/export/media        2.73G   138G  2.73G  /export/media
rpool/swap                   2G   140G  12.3M  -

Ano, rpool, rpool/export, rpool/export/home a další jsou souborové systémy. Je vidět, že pool má 140 GB, 2 GB jsou rezervovány swapu a zbytek je volný, k dispozici pro všechny. Mohu samozřejmě nastavit kvótu nebo rezervovat místo jednotlivým souborovým systémům, ale standardně se nemusím starat o to, jestli jsem náhodou nedal prostoru na média moc místa a nebo udělal root příliš malý. Autoři ZFS rádi používají přirovnání, že ZFS se má k diskům tak, jak se má virtuální paměť k RAM, tam také nemusíte alokovat x MB nějaké aplikaci, stačí přihodit paměť a ta je k dispozici všem aplikacím.

Tomu, že se souborové systémy chovají jako adresáře se budeme věnovat později, teď si pojdmě vytvořit vlastní pool:

jakub@ferda:~/zfs$ mkfile 1g pdsk1 pdsk2 pdsk3 pdsk4 pdsk5
jakub@ferda:~/zfs$ pfexec zpool create tank ~/zfs/pdsk*
jakub@ferda:~/zfs$ zpool list tank
NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
tank  4.96G  76.5K  4.96G     0%  ONLINE  -
jakub@ferda:~/zfs$ zpool status tank
  pool: tank
 state: ONLINE
 scrub: none requested
config:

	NAME                            STATE     READ WRITE CKSUM
	tank                            ONLINE       0     0     0
	  /export/home/jakub/zfs/pdsk1  ONLINE       0     0     0
	  /export/home/jakub/zfs/pdsk2  ONLINE       0     0     0
	  /export/home/jakub/zfs/pdsk3  ONLINE       0     0     0
	  /export/home/jakub/zfs/pdsk4  ONLINE       0     0     0
	  /export/home/jakub/zfs/pdsk5  ONLINE       0     0     0

errors: No known data errors

Co jsme se dozvěděli? Právě jsem vytvořil pool jménem tank, z pěti "disků" velikosti 1 GB. Pool má velikost necelých 5 GB, takže jde podle všeho o RAID 0. To ale není moc dobrý způsob jak ukládat data, že? Zkusíme to znovu se složeným a trochu bezpečnějším RAIDem.

jakub@ferda:~/zfs$ pfexec zpool destroy tank
jakub@ferda:~/zfs$ pfexec zpool create tank mirror ~/zfs/pdsk1 ~/zfs/pdsk2 mirror ~/zfs/pdsk3 ~/zfs/pdsk4 
jakub@ferda:~/zfs$ zpool list tank
NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
tank  1.98G    75K  1.98G     0%  ONLINE  -
jakub@ferda:~/zfs$ zpool status tank
  pool: tank
 state: ONLINE
 scrub: none requested
config:

	NAME                              STATE     READ WRITE CKSUM
	tank                              ONLINE       0     0     0
	  mirror                          ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk1  ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk2  ONLINE       0     0     0
	  mirror                          ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk3  ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk4  ONLINE       0     0     0

errors: No known data errors

Tady máme RAID 10. (Proč tam pořád píši to "tank"? Jen "zpool status" nebo "zpool list" by fungoval, ale nechci, aby se mi tam pletl dříve zmíněný rpool). Na pdsk5 se nedostalo, protože nemá partnera. Tak mu ho vytvoříme (aby mu nebylo smutno) a předvedeme ještě RAID 5, tady nazvaný RAIDZ1, protože obsahuje mechnismy, které obchází RAID 5 write hole (en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5_Performance). RAIDZ2 je potom RAID 6.

jakub@ferda:~/zfs$ mkfile 1g pdsk6
jakub@ferda:~/zfs$ pfexec zpool destroy tank
jakub@ferda:~/zfs$ pfexec zpool create tank raidz ~/zfs/pdsk1 ~/zfs/pdsk2 ~/zfs/pdsk3 raidz ~/zfs/pdsk4 ~/zfs/pdsk5 ~/zfs/pdsk6 
jakub@ferda:~/zfs$ zpool list tank
NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
tank  5.97G   141K  5.97G     0%  ONLINE  -
jakub@ferda:~/zfs$ zpool status tank
  pool: tank
 state: ONLINE
 scrub: none requested
config:

	NAME                              STATE     READ WRITE CKSUM
	tank                              ONLINE       0     0     0
	  raidz1                          ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk1  ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk2  ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk3  ONLINE       0     0     0
	  raidz1                          ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk4  ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk5  ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk6  ONLINE       0     0     0

errors: No known data errors

Máme tedy RAID 50. S disky se dají dělat ale i další kejkle. Mohu udělat z nemirrorované konfigurace mirrorovanou (a naopak) nebo přidat celou skupinu disků do poolu, pokud potřebuji zdalší místo. ZFS umí i nahradit menší disk větším.

jakub@ferda:~/zfs$ pfexec zpool destroy tank
jakub@ferda:~/zfs$ pfexec zpool create tank ~/zfs/pdsk1 
jakub@ferda:~/zfs$ zpool list tank
NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
tank  1016M    72K  1016M     0%  ONLINE  -
jakub@ferda:~/zfs$ zpool status tank
  pool: tank
 state: ONLINE
 scrub: none requested
config:

	NAME                            STATE     READ WRITE CKSUM
	tank                            ONLINE       0     0     0
	  /export/home/jakub/zfs/pdsk1  ONLINE       0     0     0

errors: No known data errors
jakub@ferda:~/zfs$ pfexec zpool attach tank /export/home/jakub/zfs/pdsk1 /export/home/jakub/zfs/pdsk2
jakub@ferda:~/zfs$ zpool status tank
  pool: tank
 state: ONLINE
 scrub: resilver completed after 0h0m with 0 errors on Sun Mar  8 21:27:13 2009
config:

	NAME                              STATE     READ WRITE CKSUM
	tank                              ONLINE       0     0     0
	  mirror                          ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk1  ONLINE       0     0     0  44K resilvered
	    /export/home/jakub/zfs/pdsk2  ONLINE       0     0     0  70.5K resilvered

errors: No known data errors
jakub@ferda:~/zfs$ pfexec zpool add tank mirror ~/zfs/pdsk3 ~/zfs/pdsk4 
jakub@ferda:~/zfs$ zpool list tank
NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
tank  1.98G    93K  1.98G     0%  ONLINE  -
jakub@ferda:~/zfs$ zpool status tank
  pool: tank
 state: ONLINE
 scrub: resilver completed after 0h0m with 0 errors on Sun Mar  8 21:27:13 2009
config:

	NAME                              STATE     READ WRITE CKSUM
	tank                              ONLINE       0     0     0
	  mirror                          ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk1  ONLINE       0     0     0  44K resilvered
	    /export/home/jakub/zfs/pdsk2  ONLINE       0     0     0  70.5K resilvered
	  mirror                          ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk3  ONLINE       0     0     0
	    /export/home/jakub/zfs/pdsk4  ONLINE       0     0     0

errors: No known data errors
jakub@ferda:~/zfs$ pfexec zpool destroy tank
jakub@ferda:~/zfs$ pfexec zpool create tank ~/zfs/pdsk1 ~/zfs/pdsk2 
jakub@ferda:~/zfs$ zpool list tank
NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
tank  1.98G    75K  1.98G     0%  ONLINE  -
jakub@ferda:~/zfs$ mkfile 2g ndsk1 ndsk2
jakub@ferda:~/zfs$ pfexec zpool replace tank ~/zfs/pdsk1 ~/zfs/ndsk1 
jakub@ferda:~/zfs$ pfexec zpool replace tank ~/zfs/pdsk2 ~/zfs/ndsk2
jakub@ferda:~/zfs$ zpool list tank
NAME   SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
tank  3.98G  94.5K  3.98G     0%  ONLINE  -

Jak je vidět, když nahradím oba disky většími, kapacita poolu se zvýší. Umí tohle váš volume manager?

Co je nepříjemné, je, že ZFS neumí odstranit zařízení z poolu. Vyměnit ho za jiné nebo udělat ze zrcadlené konfigurace nezrcadlenou jde, ale pokud si vytvořím (dejme tomu) RAID 0 ze dvou disků, už z něj nikdy jeden disk neudělám. Údajně se na tom pracuje (v TODO listu již je to dlouho, ale teď to prý začalo vadit nějakému velkému zákazníkovi, takže na tom někdo skutečně začal dělat), ale ve spoustě použítí to nevadí.

Jaké má tohle propojení výhody, krom toho, že nemusím přemýšlek, kolik místa kam přiřadit? No, hlavní důsledky jsou dva, rychlost a bezpečnost. Tady v psaných příkladech to není vidět, ale pokud vytvořím nový pool, mám ho hned a nemusím počkat, až systém sesynchronizuje disk, protože ZFS samozřejmě ví, že v prázdném poolu není co synchronizovat. A když budu měnit vadný disk za jiný a v poolu mám 100 GB dat, bude ZFS kopírovat jen 100 GB dat, i když půjde o terabytové disky. Pokud jde o bezpečnost, ZFS dělá kontrolní součty kde čeho, a pokud narazí na to, že je nějaký kontrolní součet špatně, zkusí vzít data z jiného místa a taktně upozorní správce, že s diskem by mohlo být něco v nepořádku. Pokud žádné jiné misto, ze kterého by šlo vzít data, není, odmítne data vydat úplně -- politika Solarisu je v tomhle oznámit chybu a zastavit běh aplikace, raději než vydat špatná data, která by mohla vést k naprosto nepředvídatelému (a třeba také nikdy neodhalenému) chování.

Trochu o vnitřnostech

Jen malá odbočka. Jak vlastně vypadá ZFS uvnitř? Proč nepotřebuje fsck, jak ručí za správnost dat? Když to zjednoduším (a vypustím nižší vrstvy), ZFS vypadá jako strom. Co je ale zajímavé, je to, že jde o strom, který zhusta praktikuje copy-on-write, a kvůli tomu zůstává konzistentní napříč různými operacemi.

Dejme tomu, že se rozhodnu vytvořit nový soubor ve svém domovském adresáři. Vytvořím soubor, souborový systém uloží jeho datové bloky a vytvoří nový blok pro adresář, do kterého nový soubor ukládám, uloží ho někam do volného místa a původní adresář nechá, kde byl. Takhle bude postupovat, dokud nevytvoří aktualizovanou kopii kořenového adresáře a nezapíše ji do superbloku. Tohle je první chvíle, kdy se něco přepisuje, a jde o atomickou operaci. Takže jsem buď úspěšně uložil nový soubor a mám nový kompletní a konzistentní strom (ZFS zapisuje superblok, až když si je jisté všemi nižšími úrovněmi), nebo mi někde v průběhu vypadl proud a pak se sice nový soubor nezapsal, ale superblok pořád úspěšně odkazuje na předešlou a neporušenou verzi dat.

Všechny vrstvy stromu mají kontrolní součty a ukládají se ve více kopiích (standarně mají data jednu kopii, metadata 2 + počet kopií dat, jde to ale změnit). Pokud bych měl ale o konzistenci dat pochybnosti, mohu požádat pool, aby se "vykartáčoval" pomocí zpool scrub, systém potom projde všechna data a přepočítá jejích kontrolní součty, a pokud neodpovídají, opraví je z replik. Manuál doporučuje kartáčovat disky pravidelně, každý týden až měsíc.

Pokud jde o pořadí operací, ZFS dává přednost čtení a zápisy si řadí do fronty a provede je, až když už v ní visí dlouho, nebo když nemá co dělat. Logika za tím je ta, že nikoho nezajímá kdy proběhne zápis, zatímco na čtení obvykle někdo čeká. Co když ale někdo chce, aby byl zápis zcela jistě proveden, než mu ZFS vrátí úspěch? K tomuhle slouží ZIL, ZFS Intent Log. Funguje trochu jako žurnál, tedy asynchronní zápisy se uloží do RAM, synchronní zápisy putují do ZILu a jsou ihned zapsány na disk, a když má ZFS čas, zapíše je na disk a smaže ze ZILu. Pokud by náhodou (například) vypadl proud a ZFS je nemohlo normálně zapsat, přehraje ZIL při příštím importu poolu a splní tak, co slíbilo. ZIL se normálně nachází na discích poolu, ale mohu ho umístit na jiné zařízení, třeba SSD nebo nějakou NVRAM, pokud bych chtěl zrychlit synchronní zápisy.

Filesystém jako adresář?

Dlužím vám vysvětlení ohledně toho, že jsou souborové systémy jako adresáře. Tomu, že si všechny berou místo ze společného poolu, jsme se už věnovali, takže teď je jen stačí hierarchicky uspořádat a máme to. Souborový systém v podání ZFS je tedy chytřejší adresář, se kterým se dají dělat kejkle. Krom toho, že na první pohled vidíme, kolik místa zabírá. Souborových systémů můžeme teoreticky vytvořit, kolik chceme (tedy přesněji 2^48, což je skoro totéž), ale není dobré to přehánět, spousta algoritmů v systému pracuje v O(počet souborových systému), takže stroj s desítkami tisíc souborových systémů nebude startovat zrovna rychle (ale je přislíbeno něco s tím udělat na další verzi). Když vytvořím pool, standardně se mi vytvoří první souborový systém, který se jmenuje stejně jako pool, a připojí se do /jméno_poolu.

Začneme snapshoty. Vytvořit souborový systém je snadné, vytvořit snapshot také.

jakub@ferda:/tank# zfs create tank/testy
jakub@ferda:/tank# zfs snapshot tank/testy@testovaci-snapshot
jakub@ferda:/tank# zfs list -r -t all tank

NAME                                           USED  AVAIL  REFER  MOUNTPOINT
tank                                           130K  1.95G    19K  /tank
tank/testy                                      18K  1.95G    18K  /tank/testy
tank/testy@testovaci-snapshot                     0      -    18K  -

Snapshoty jsou jen ke čtení a standardně se vytvoří jen pro jmenovaný souborový systém, ne pro jeho podsystémy, můžeme ale požádat o rekurzivní snapshot přídáním "-r". Nezabírají teméř žádné místo, dokud původní data nezmění, a potom zabírají jen tolik místa kolik zabírají změny. Ze snapshotu mohu vytvořit klon, tedy snapshot, do kterého je možné zapisovat. Ke snapshotu se lze vrátit pomocí zfs rollback a k jejich likvidaci (stejně jako k likvidaci nepohodlných souborových systémů) poslouží zfs destroy.

Souborové systému maji spoustu vlastností, které se dědí. Dostat se k nim dá pomocí zfs get all pool/fs. Je jich spousta a manuálová stránka zfs obsahuje jejich vysvětlení, ale pár jich za zmínku stojí.

  • Je možné nastavit kompresi: zfs set compression=on (kompresle lzjb, rychlý kompresní algoritmus, který dal dohromady Jeff Bonwick) nebo zfs set compression=gzip, trochu si tím urychlit diskové operace, pokud máte rychlý procesor -- komprese a dekomprese je rychlá a znamená to méně přečtených nebo zapsaných bloků. Pak začne dávat smysl vlastnost compressratio.
  • zfs set quota a zfs set reservation moc popisu nepotřebují, snad jen, že krom nich ZFS obvyklé uživatelské a skupinové kvóty neumí a umět pravděpodobně nebude.
  • Lze vypnout atime (vlastnost atime) nebo kontrolní součty (vlastnost checksum) ale to zrovna asi není dobrý nápad.
  • Bod připojení můžete přenastavit ve vlastnosti mountpoint a nechat systém, ať připojí souborový systém třeba zcela mimo hierarchii začínající jménem poolu. K tomu není potřeba dělat cokoli s fstab, ale pokud byste chtěli používat fstab, jde mountpoint nastavit na legacy.
  • Pokud si chcete snapshoty jen tak procházet a neoperovat s nimi jen pomocí příkazu zfs, jde nastavit snapdir na visible (namísto hidden) a pak je objevíte v souborový_systém/.zfs/spanshot/jméno_snapshotu.
  • A poslední zajímavá možnost: Pokud chcete provozvat databázi, je dobré nastavit vlastnost recordsize na velikost bloku databáze, ZFS jinak používá autodetekci a databáze z toho často nejsou moc nadšené.

Všechny tyhle vlastnosti se aplikují jen na nové nebo změněné soubory, je to znát hlavně u komprese a recordsize, nastavení vlastnosti magicky "nepřechroustá" všechna data.

Drobnosti na závěr

Sliboval jsem NFS a CIFS, že? U NFS je to jednoduché, zfs set sharenfs=on pool/fs nebo častěji zfs set sharenfs=rw se postará o všechno, co potřebujete (tedy mimo zabezpečení). Systém sám nastartuje služby potřebné pro NFS server, pokud neběží (pokud souborový systém odsdílíte, nevypne je, ale při příštím restartu se nezapnou pokud nebudou potřeba). U CIFS je to trochu složitější, protože je potřeba nastavit pracovní skupinu a přenastavit PAM, aby generoval hesla použitelná pro CIFS, protože CIFS server integrovaný v jádře OpenSolarisu neumí anonymní režim jako Samba, ale zfs set sharesmb=on je vaším přítelem. Jestli se všechno vyexportovalo, jak mělo, vám napoví utilita sharemgr. Mezi vlastnostmi lze najít i shareiscsi, ale tím se tu nebudu zabývat, protože je na cestě přepracovaný systém pro exportování svazků a v příští verzi (tedy za měsíc) už tahle možnost pravděpodobně nebude existovat.

Kdyz jsem ukazoval rpool, byl tam vidět také swap a dump prostor (prostor pro crashdumpy). Neměly mountpoint a pravděpodobně to nejsou souborové systémy, jak to? Je to tak, jsou to virtuální svazky, které lze pomocí ZFS tvořit. Konkrétně zfs create -V velikost cesta, svazek se pak objeví v /dev/zvol/dsk/cesta. Krom toho, že je můžeme exportovat, dělat snapshoty, klony, nakonfigurovat je, aby byly komprimované, a vůbec s nimi provádět psí kusy (tedy všechno, co jde se souborovými systémy), jde pomocí parametru -s vytvořit i "sparse volume", tedy vytvoří se svazek, ale místo pro něj se nerezervuje. Ve storage terminologii se tomu říká thin provisioning a je to užitečná funkce (můžete ze dvou 500GB disků rozdistribuovat klientům několik TB), ale říkáte si o hrozivé problémy, pokud vám dojde místo (SCSI write chyby a tak).

Předposlední vychytávka. ZFS poměrně agresivně cachuje data. Ale každá RAM je malá, disky jsou velké a dat je hodně. ZFS umí přidat k poolu cachovací zařízení. Funguje to tak, že když ZFS dochází paměť v RAM a potřebuje z ní vyhodit nacachovanou stránku a přesto má pocit, že by mohla být v budoucnu potřeba, přesune ji do cache druhé úrovně (neplést s L2 cache procesoru). Dobrým HW pro tyhle účely jsou SSD, jsou o hodně rychlejší než klasické disky, a přitom často nemají kapacitu na to, aby se jimi daly klasické disky nahradit, a o 128 GB cache člověk jen tak nezavadí.

A úplně nakonec, říkal jsem, že o místa, kam se připojuje ZFS, se nestará fstab a mount. Jak se tedy zbavit poolu, jinak než ho zničit nebo vypnout počítač? Co když budu potřebovat odpojit pool s daty a přenést ho jinam? To samozřejmě jde i za chodu (pokud to tedy není rpool) příkazem zpool export. Opakem je pak zpool import, který prohledá všechny disky a poohlédne se po poolech. Je možné mu napovědět, na kterých discích hledat, nebo stanovit alternativní název (dva rpooly by nedělaly dobrotu) nebo kořenový adresář pro imporovaný pool.

Příště

To je pro dnešek vše. Přístě budou sítě, služby a balíčkovací systém.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

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

Komentáře

Vložit další komentář

17.3.2009 11:00 Yenya
Rozbalit Rozbalit vše Re: OpenSolaris - 3 (ZFS)
Jak je vidět, když nahradím oba disky většími, kapacita poolu se zvýší. Umí tohle váš volume manager?

Proč by neměl umět? Třeba LVM v Linuxu to sice nedělá jedním krokem (je třeba vgextend na pridani noveho disku do VG, pvmove na presun dat ze stareho, a vgreduce na odstraneni stareho disku z VG), ale samozrejme to umi. To je prece zakladni vlastnost kazdeho volume manageru.

Ted se ale divam, ze LVM umi i pvresize, pokud se zmeni velikost diskove oblasti za behu (napriklad ze oblast sama je na nejakem HW diskovem poli).

-Yenya, http://www.fi.muni.cz/~kas/blog/

17.3.2009 11:23 Tomas Dzik
Rozbalit Rozbalit vše Re: OpenSolaris - 3 (ZFS)

Ovsem k tomu, abyste toho mohl vyuzit, potrebujete aby i filesystem podporoval growfs. To nastesti vetsina filesystemu dneska uz umi, ale na zfs se mi libi, ze to vubec nemusim delat. ZFS zacne misto pridane do poolu pouzivat automaticky s tim, jak pribyva dat na filesystemu.

Osobne bych (na rozdil od autora clanku) pri popisu ZFS volume manager vubec nezminoval, protoze jakekoliv srovnani dost kulha. ZFS je zkratka filesystem, ktery je navrzen tak, aby mohl ukladat data na vice disku zaroven a umel pri tom zajistit pozadovanou redundanci dat.

20.3.2009 15:25 ..... Izak ..... | skóre: 14
Rozbalit Rozbalit vše Re: OpenSolaris - 3 (ZFS)
No to je sice hezke, ale na linux ZFS asi nikdy nebude, takze me tenhle FS vubec nezjima, krom toho jeste neni tak odladeny jako LVM, swraid a ext3 ...
20.3.2009 17:45 Milan Jurik | skóre: 21 | blog: Komentare | Ova
Rozbalit Rozbalit vše Re: OpenSolaris - 3 (ZFS)
Kdyz vas nezajima, proc to tu diskutujete? :-)

V cem neni odladeny tak jako ext3 (a podpurne technologie jako LVM ci swraid)? Napriklad v tom, ze nemusim mit zahadne poruseni ext3 na lvm, i kdyz je dany desktop vypinan pouze ciste, a cekat mnoho minut na to, az dobehne fsck?
17.3.2009 12:46 Jiri Bajer | skóre: 33 | blog: Sarimuv koutek | Praha
Rozbalit Rozbalit vše Doplneni informaci o ZFS

Stalo by za to jeste zminit, jak vypada bootovani ze ZFS rootu a jaky dopad to ma na syntaxi zaznamu v GRUBu. Dalsi podle me nesamozrejma vec, ktera by urcite stala za par slov je vzhled zaznamu ve fstab + jestli nastroje na praci s disky, ktere ocekavaji devicefile jsou schopne pracovat i se ZFS, nebo potrebuji prepsat.

Kdyz uz byla rec o vnitrnostech, stalo by za to naznacit moznosti ladeni a prochazeni datovymi strukturami ZFS - mnozstvi urovni abstrakce, slozitost datovych struktur, vnitrni komprese, pocet dereferenci, ktere vedou od cesty+jmena souboru k obsahu souboru.

Jako predposledni vec bych rad videl pametovou narocnost a rychlost ZFS na kancelarskem desktopu/notebooku/netbooku - tedy tam, kde je nejpravdepodobnejsi, ze nekdo bude OpenSolaris zkouset nainstalovat. Treba uz nekdo zkusil zmerit rychlost bootu, rychlost kopirovani/mazani hromady malych souboru a tak?

Mam pocit, ze zbavit se problemu s volume managery coby duvod vzniku ZFS je eufemismus pro funkcni neuplnost LVM a licencni poplatky za Veritas Volume Manager.

Nakonec bych poprosil o min eskamotersky/meganadseny ton clanku, takhle to vyzniva spis jako pokus o propasovani PR clanku o vyvojove verzi komercniho UNIXu do webu zamereneho na Linux. Kazda technologie ma svoje vyhody i nevyhody - at komercni, tak svobodna a prehnane nadseni muze s sebou nest jednostrannost...

Tak jak tak ale dekuju za odborny technologicky clanek (byt z hlediska Linuxu offtopic)!

17.3.2009 13:13 Milan Jurik | skóre: 21 | blog: Komentare | Ova
Rozbalit Rozbalit vše Re: Doplneni informaci o ZFS
Take bych poprosil o trosku mene konfrontacne naladeny prispevek, takze od konce:

1) rekl bych, ze abclinuxu.cz uz davno neni jen o Linuxu, ale o open source technologiich obecne

2) je Nexenta ci BeleniX vyvojova verze komercniho UNIXu? Nerekl bych. A presto maji to same open source zfs, presne to same jadro. Necekal bych, ze zrovna ty nevis o opensolaris.org...

3) do nekonecna omilane, ze je treba mit oddeleny volume manager a fs, ach jo. Mam osobni nazor, ze volume manager je jen historicka berlicka suplujici neschopnost file systemu pracovat s vice disky. V designu ZFS tohle slouceni proste "tak nejak vyplynulo samosebou". A je nesmyslne vytvaret prebytecne vrstvy, ktere neodstranuji duplicitu kodu a naopak snizuji operacni schopnosti a uzivatelskou pouzitelnost. Nebo se tu dostaneme i do sporu micro vs. monolit jadro

4) osobne uzivam ZFS na 2 noteboocich, ale na mereni vykonosti filesystemu expert nejsem. Co vim, tak je ZFS docela pametove hladove, kdyz chce (ale muze byt limitovano). Rychlost ZFS mi tam limitujici neprijde (jen me stve prace s rozsahlymi soubory, ale nemam moc cas to studovat).

5) neni tenhle clanek spise pro normalni uzivatele? Nebo chces zacit rozebirat zde i zdb?

6) magii ZFS bootu a findroot neznam, /etc/vfstab muze a nemusi byt systemem bran v potaz, zalezi na nastaveni jednotlivych zfs a co se tyce prace devices, tak ty zfs nijak nemaskuje, stale je v /dev/ vidis, takze jsem asi moc nechytil smysl tohohle dotazu.
22.3.2009 09:36 Jiri Bajer | skóre: 33 | blog: Sarimuv koutek | Praha
Rozbalit Rozbalit vše Re: Doplneni informaci o ZFS

1) To je hodne subjektivni - moje kriterium pro offtopic je "nemuzu si to plnohodnotne nainstalovat k sobe na pocitac s Linuxem".

2) Kachna i husa maji zobak a kridla, nejsou to slepice a presto jsou to ptaci. Tohle neni argument, sorry. ;-) Zkusim byt konkretnejsi (byt Linuxocentricky):

PR clanek:

ucelem je propagovat znacku/produkt, nikoliv podat objektivni a ucelene informace, typicky popisuje jen klady a aporum setaktne vyhyba, pokud nekdo poukazuje na neobjektivnost, je ostrakizovan zastupci znacky

vyvojova verze:

existuje jina verze, ktera se bezne nasazuje v produkci, zatimco tahle verze je prozatim na hrani - casem se z tehle verze stane neco, co se bude nasazovat v produkci

komercni UNIX:

puvodne uzavrene jadro i userland, casem cast userlandu nahrazovana GNU nastroji, ale prednost je stale davana zpetne kompatibilite pred jednoduchosti a modernosti, vyvoj, architekturu a zasadni rozhodnuti ridi jedina firma, ktera ma z daneho UNIXu zisky, firma se snazi vymezovat produkt oproti Linuxu jako neco pokrocilejsiho (Linux na hrani a do male firmy, UNIX do datacentra) a snazi se, aby technologie v produktu zustaly a nebyly re-implementovany v Linuxu, kde by firma ztratila kontrolu nad vyvojem

3) Cetls Art of UNIX programming? Monolit neni UNIXovy - UNIXova cesta je spousta malych jednoucelovych a opakovatelne pouzitelnych komponent - KISS. Usnadnuje to ladeni, udrzbu, modernizaci (nahradit komponentu je snazsi), kombinaci s produkty tretich stran (tohle je pro komercni technologii vetsinou nezadouci), umoznuje to snadne prispivani do projektu nezavislymi vyvojari (snadne pochopeni kodu). Diskuse niz presne tohle ukazuje...

4) Tak proc na tenhle bod reagujes, kdyz nemas odpoved? ;-)

5) To neni odpoved, jen mlzeni - totez, co bod 4)

6) Totez co bod 4)

Uz se k tvym reakcim nebudu vracet, protoze me flames fakt nezajimaji. Muj komentar smeroval na autora clanku, ne na bojovnika za svatou pravdu...

22.3.2009 11:44 Milan Jurik | skóre: 21 | blog: Komentare | Ova
Rozbalit Rozbalit vše Re: Doplneni informaci o ZFS
Vim, ze uz nebudes reagovat, ale nekdy zvaz, co a jak pises, protoze styl, kterym jsi reagoval, byl kontroverzni. A schovavat se za to, ze nemas rad "flame", kdyz si o nej zakladas, neni zrovna nejlepsi zaver.

Nebudu tve "argumenty" tedy dale rozebirat, jen jsem podotknul, ze tva reakce byla cilene provokativni, bojovniku za svatou pravdu :-)
23.3.2009 18:38 Tomáš Dzik
Rozbalit Rozbalit vše Re: Doplneni informaci o ZFS

 ad 3) To, co píšete, obecně skutečně platí. Je ale otázkou, kde je nejlepší místo pro to, kde vést dělící čáru mezi jednotlivými komponentami. Mám pocit, že rozdělovat zrovna volume manager a filesystem není dobrý nápad z následujících důvodů:

a) Ukazuje se, že při tomto rozdělení je třeba, aby se podobné úkoly dělaly dvakrát. Jednou ve volume manageru a jednou ve filesystému. Např. pro zajištění rychlé resynchronizace mirroru se používá DRL (dirty region logging). Ten se musí někam ukládat, stejně jako konfigurace volume manageru - typicky někam na mirrorovaný disk. Takže už Vám na disku vzniká ne zcela jednoduchá struktura. Navíc musíte řešit její updatování tak, aby bylo pokud možno atomické (odolné proti tomu, když Vám server spadne právě při změně konfigurace volume manageru), správně verzované (aby se nepoužila zastaralá konfigurace např. z odpojené poloviny mirroru). Přitom podobné problémy řešíte ještě jednou v rámci filesystému.

b) Pokud chcete mít možnost odebírat z volume manageru disky, musíte být schopen filesystému nějak sdělit, která data má odmigrovat a kam. V takovém případě ztratíte jednoduchost rozhraní + filesystém musí rozumět tomu, že prostor pod ním tvoří jednotlivé disky. Tedy dostal jste se k integrovanému řešení.

c) V případě, že filesytem neví o tom, že běží nad více disky, nemáte ani možnost optimalizovat výkon použitím více různých druhů disků pro různé struktury filesystému.

Např. Oracle taky spíše doporučuje používat ASM (automatic storage management), který má přehled o fyzických discích, než umístit všechny datové soubory na jeden volume volume manageru. (Uvědomuju si, že tady jsem hodně zjednodušil a že plánovat storage pro databáze je fakt věda.)

 

Dovolím si přirovnání z oblasti dopravy: Kdysi se používaly autobusy, které se skládaly z tažného autobusu a vlečňáku, připojeného pomocí dobře definovaného rozhraní (oje) k tažnému autobusu. Jednalo se o jednoduché, řešení a komponenta vlečňáku byla snadno nahraditelná např. traktorem. A přesto dnes všichni považují integrované řešení (autobus s kloubem) za výrazně lepší a výhodnější ;-)

Myslím, že podobný osud čeká i oddělený volume manager.

21.3.2009 09:07 Jakub J
Rozbalit Rozbalit vše Re: Doplneni informaci o ZFS

Diky za odezvu, zkusim odpovedet.

Testy pametove narocnosti a vykonu se delaji pomerne spatne, protoze OpenSolaris neumi fungovat na jinem fs nez ZFS, a tradicniho Solarisu by to sice slo, ale slo by spis o porovnani OpenSolarisu a Solarisu. Porovnani s Linuxem je spis porovnani celeho systemu nez porovnani fs. Dobre zpracovane porovnani souborovych systemu najdete tady: http://bulk.fefe.de/lk2006/ (a u poznamek autora se pravdepodobne pobavite), ale sam na to nemam hardware ani prostredky, a testovanim jen na nejake platforme se toho clovek moc nedozvi.

Na podrobnosti o vnitrnostech bohuzel nezbylo misto.

Pokud jde o nadseny ton, o dva clanky zpatky mi bylo vycitano ze se moc opiram do Sunu, a ted tohle. Bojim se, ze se nezavdecim vsem ;)

22.3.2009 09:45 Jiri Bajer | skóre: 33 | blog: Sarimuv koutek | Praha
Rozbalit Rozbalit vše Re: Doplneni informaci o ZFS

Dik za rozumny pristup!

Ad odkaz: dik, to je hodne zajimavej benchmark!

Ad nadsenej ton: slo mi spis o to, aby se pohromade objevily pro i proti - anebo byl clanek oznacenej jako reklama. ;-) Vsem se urcite neda zavdecit, ale napr. par linku na dalsi informace by urcite neskodilo...

 

23.3.2009 12:43 Jakub J
Rozbalit Rozbalit vše Re: Doplneni informaci o ZFS

No, pravdou je, ze nevhody ZFS moc nevidim. Ta vlastnost ze nemuzu odebrat zarizeni z raid 0 je neuveritelne otravna, a muzete se snadno dostat do stavu kdy vas ceka uz jen tar, zpool destroy, zpool create, untar, ale pokud na to myslite tak se s tim da zit. Nepritomnost uzivatelskych kvot je dana strukturou -- ta cast fs ktera alokuje misto na data a tedy se stara o to jestli jeste jde zapisovat je hodne hluboko pod posixovou vrstvou a nema o nejakych uzivatelich ani potuchy. Navic, kombinace snapshotu a kvot je mala nocni mura, protoze bud se snapshoty do kvot nepocitaji, a pak ta kvota moc nemuze, nebo se pocitaji a uzivatel ji muze zabrat tim ze meni jeden svuj maly soubor, a najednou nema misto (coz je nemile zvlast kdyz jsou snapshoty nastavene adminem a uzivatel s tim nic neudela). Taky delat klasicky quotacheck na nekolika terabajtovem fs nen moc dobry napad. A ZFS sice moc nefunguje pod linuxem, ale podpora ve FreeBSD a MacOSu ho dela kompatibilnejsi nez kdejaky dalsi souborovy system.

S benchmarky je to obecne nepekne. Aby takovy benchmark vyhovel vetsine uzivatelu, musel by se zabyvat jak malymi SSD pro mininotebooky (a resit jak se fs chova kdyz je skoro plny, jak se chova na SSD a jak se chova kdyz misto dojde uplne), tak desktopovymi disky, tak pro servery resit jak se FS + volume manager (neni-li zabudovany jako do ZFS a brtfs) chovaji na raidu 1, raidu 10, raidu 5, a jak velky vliv ma cachovani, nebo jak se na nem chovaji databaze. Krom toho je problem s testovacimi nastroji, protoze spousta benchmarku je optimalizovana pro jedenu platformu, a muzete se snadno dostat do situace kdyz delate ekvivalent testotvani vykonu souboroveho serveru bez pouzivani sendfile() nebo ekvivalentu, coz je k nicemu, protoze spousta serverovych aplikaci ma specialni optimalizace pro ten ktery operacni system.

Tohle vsechno sezere velke mnozstvi casu (treba desitky hodin) a je tedy otazka kdo to zaplati. Redakcim casopisu se za par grafu asi nebude chtit platit nejake velke castky, a pokud benchmark plati nejaka firma, je otazka jak z toho profituje a jestli nechce nejak priohnout vysledky. Mozna tak akademicka sfera a udelat si z toho bakalarku nebo diplomku (za kterou sice penize nejsou, ale clovek ji musi udelat tak jako tak), ale spousta lidi uz ma po skole, a i kdyby ne tak spousta oponentu a komisi se na zaverecne prace typu reserse diva skrz prsty protoze "prece nevytvari nic noveho".

20.3.2009 15:31 ..... Izak ..... | skóre: 14
Rozbalit Rozbalit vše Re: OpenSolaris - 3 (ZFS)
Nen LVM je nutny proc ? * Mam na vyber vicero FS * Muzu pouzivat rawdevice napr pro DB * Bezne z nich bezi produkcni virtualni stroje z Xenu nebo KVM, proc ? protoze existuje Cluster LVM a nemusim pak pouzivat GFS ... takze vsechny Dom0 vidi vsechny LVM, ale jsou pouzivany vzdy jednim.

... ale ze solaris ma LVM uplne na nic, nebo dost kostrbaty, ze tam sice jde udelat neco jako SWraid, ale kazdy si radeji koupi Veritas, ktery taktez umi i cluster.
20.3.2009 17:53 Milan Jurik | skóre: 21 | blog: Komentare | Ova
Rozbalit Rozbalit vše Re: OpenSolaris - 3 (ZFS)
Argument rawdevice beru, teoreticky to navrh ZFS umoznuje, ale dane API nebylo dosud zverejneno. Na vyber mezi vice FS? Radsi jeden a poradne (vynechme fs pro specialni ucely, kde stejne LVM postrada smysl), at jde pripadne i dobre tunit.

Co se tyce Cluster LVM, jini pro to uzivaji jine nastroje nad ZFS. A? Jak to souvisi se ZFS filesystemem?

Pokud vam vadi SVM, tak ano, to chapu, ma sve limity. Chutovka je treba v kombinaci s Live upgrade. Ale ani jedno z toho se OpenSolarisu netyka.

A nerekl bych, ze Veritas zaznamenava narust pouziti sveho reseni. Ale je pekne, ze Linuxar podporuje proprietarni reseni ;-)
26.3.2009 19:45 darkenik
Rozbalit Rozbalit vše Re: OpenSolaris - 3 (ZFS)

tak je mozne pouzivat v ZFS aj raw device podobne ako pri swape na ZFS,.

co sa tyka clustrov a volume managerov v solarise, tak to vie aj SVM, aj ZFS. Je pravda ze Veritas ma svoje vyhody, mno myslim, ze tie pri porovnani zo ZFS padaju (aj ked vo veritase je mozno povedat na ktorych fyzickych diskoch v groupe sa bude volume nachadzat , co tusim ZFS nevie ).

Založit nové vláknoNahoru

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