Letos na jaře jsme již probrali některá úvodní témata, např. и . Ve druhém z nich jsme dokonce slíbili pokračovat ve studiu výkonu různých vícediskových topologií v ZFS. Toto je souborový systém nové generace, který je nyní implementován všude: od na .
Inu, dnes je ten nejlepší den na seznámení se ZFS, zvídaví čtenáři. Jen vězte, že podle skromného názoru vývojáře OpenZFS Matta Ahrense "je to opravdu těžké."
Než se ale dostaneme k číslům – a slibuji, že budou – u všech možností konfigurace ZFS s osmi disky si musíme promluvit o как Obecně platí, že ZFS ukládá data na disk.
Zpool, vdev a zařízení
Tento úplný diagram fondu obsahuje tři pomocné vdev, jeden z každé třídy a čtyři pro RAIDz2
Obvykle není důvod vytvářet fond neshodných typů a velikostí vdev – ale pokud chcete, nic vám v tom nebrání.
Abyste skutečně porozuměli systému souborů ZFS, musíte se blíže podívat na jeho skutečnou strukturu. Za prvé, ZFS sjednocuje tradiční úrovně správy svazků a souborového systému. Za druhé, používá transakční mechanismus kopírování při zápisu. Tyto vlastnosti znamenají, že systém se strukturálně velmi liší od běžných souborových systémů a polí RAID. První sadou základních stavebních bloků, kterým je třeba porozumět, jsou úložný fond (zpool), virtuální zařízení (vdev) a skutečné zařízení (device).
zpool
Úložný fond zpool je nejvyšší strukturou ZFS. Každý fond obsahuje jedno nebo více virtuálních zařízení. Každý z nich zase obsahuje jedno nebo více skutečných zařízení (zařízení). Virtuální fondy jsou samostatné bloky. Jeden fyzický počítač může obsahovat dva nebo více samostatných fondů, ale každý je zcela nezávislý na ostatních. Fondy nemohou sdílet virtuální zařízení.
Redundance ZFS je na úrovni virtuálního zařízení, nikoli na úrovni fondu. Na úrovni fondu neexistuje absolutně žádná redundance – pokud se ztratí jakýkoli disk vdev nebo speciální vdev, ztratí se spolu s ním i celý fond.
Moderní fondy úložišť mohou přežít ztrátu mezipaměti nebo protokolu virtuálního zařízení – i když mohou ztratit malé množství špinavých dat, pokud ztratí protokol vdev během výpadku napájení nebo selhání systému.
Existuje běžná mylná představa, že „datové pruhy“ ZFS jsou zapsány v celém fondu. To není pravda. Zpool není vůbec vtipný RAID0, je spíše vtipný se složitým variabilním distribučním mechanismem.
Záznamy se většinou rozdělují mezi dostupná virtuální zařízení podle dostupného volného místa, takže se teoreticky zaplní všechny najednou. V pozdějších verzích ZFS se bere v úvahu aktuální využití (vytížení) vdev – pokud je jedno virtuální zařízení výrazně vytíženější než jiné (například kvůli zátěži čtení), bude dočasně přeskočeno pro zápis, přestože má nejvyšší volnou prostorový poměr.
Mechanismus detekce využití zabudovaný do moderních metod alokace zápisu ZFS může snížit latenci a zvýšit propustnost během období neobvykle vysokého zatížení – ale ne carte blanche na nedobrovolném míchání pomalých HDD a rychlých SSD v jednom fondu. Takový nerovný fond bude stále fungovat rychlostí nejpomalejšího zařízení, to znamená, jako by byl celý složen z takových zařízení.
vdev
Každý fond úložiště se skládá z jednoho nebo více virtuálních zařízení (virtuální zařízení, vdev). Každý vdev zase obsahuje jedno nebo více skutečných zařízení. Většina virtuálních zařízení se používá pro jednoduché ukládání dat, ale existuje několik pomocných tříd vdev, včetně CACHE, LOG a SPECIAL. Každý z těchto typů vdev může mít jednu z pěti topologií: jedno zařízení (jedno zařízení), RAIDz1, RAIDz2, RAIDz3 nebo zrcadlo (zrcadlení).
RAIDz1, RAIDz2 a RAIDz3 jsou speciální varianty toho, co by staří nazvali RAID s dvojitou (diagonální) paritou. 1, 2 a 3 ukazují, kolik paritních bloků je přiděleno pro každý datový pás. Místo samostatných disků pro paritu rozdělují virtuální zařízení RAIDz tuto paritu mezi disky polorovnoměrně. Pole RAIDz může ztratit tolik disků, kolik má bloků parity; pokud ztratí další, zhroutí se a vezme si úložiště s sebou.
V zrcadlených virtuálních zařízeních (mirror vdev) je každý blok uložen na každém zařízení ve vdev. Ačkoli jsou nejběžnější zrcadla se dvěma šířkami, v zrcadle může být libovolný počet zařízení – ve velkých instalacích se často používají trojité pro lepší čtení a odolnost proti chybám. Zrcadlo vdev může přežít jakoukoli poruchu, pokud alespoň jedno zařízení ve vdev nadále funguje.
Jednotlivé vdev jsou ze své podstaty nebezpečné. Takové virtuální zařízení nepřežije jediné selhání – a pokud se použije jako úložiště nebo speciální vdev, pak jeho porucha povede ke zničení celého fondu. Buďte zde velmi, velmi opatrní.
CACHE, LOG a SPECIAL VA mohou být vytvořeny pomocí kterékoli z výše uvedených topologií – ale pamatujte, že ztráta SPECIAL VA znamená ztrátu fondu, takže je vysoce doporučena redundantní topologie.
zařízení
Toto je pravděpodobně nejsnáze pochopitelný termín v ZFS - je to doslova blokové zařízení s náhodným přístupem. Pamatujte, že virtuální zařízení se skládají z jednotlivých zařízení, zatímco fond se skládá z virtuálních zařízení.
Disky – ať už magnetické nebo polovodičové – jsou nejběžnější bloková zařízení, která se používají jako stavební bloky vdev. Každé zařízení s deskriptorem v /dev však bude stačit, takže celá hardwarová pole RAID lze použít jako samostatná zařízení.
Jednoduchý raw soubor je jedním z nejdůležitějších alternativních blokových zařízení, ze kterých lze sestavit vdev. Testovací bazény od je velmi praktický způsob, jak zkontrolovat příkazy fondu a zjistit, kolik místa je k dispozici ve fondu nebo virtuálním zařízení dané topologie.
Testovací fond můžete vytvořit z řídkých souborů během několika sekund – ale nezapomeňte poté odstranit celý fond a jeho součásti
Řekněme, že chcete umístit server na osm disků a plánujete použít 10 TB disky (~9300 GiB) – ale nejste si jisti, která topologie nejlépe vyhovuje vašim potřebám. Ve výše uvedeném příkladu vytvoříme testovací fond z řídkých souborů během několika sekund – a nyní víme, že RAIDz2 vdev osmi 10TB disků poskytuje 50 TiB využitelné kapacity.
Další speciální třídou zařízení je SPARE (spare). Zařízení vyměnitelná za běhu, na rozdíl od běžných zařízení, patří do celého fondu a ne do jediného virtuálního zařízení. Pokud vdev ve fondu selže a k fondu je připojeno a dostupné náhradní zařízení, automaticky se připojí k postiženému vdev.
Po připojení k postiženému vdev začne náhradní zařízení přijímat kopie nebo rekonstrukce dat, která by měla být na chybějícím zařízení. V tradičním RAID se to nazývá přestavba, zatímco v ZFS se to nazývá resilvering.
Je důležité poznamenat, že náhradní zařízení trvale nenahrazují vadná zařízení. Toto je pouze dočasná náhrada za účelem snížení doby degradace vdev. Poté, co správce nahradí vadné vdev, obnoví se redundance tohoto trvalého zařízení a SPARE se odpojí od vdev a vrátí se do práce jako náhradní pro celý fond.
Datové sady, bloky a sektory
Další sada stavebních bloků, kterým je třeba na naší cestě ZFS porozumět, je méně o hardwaru a více o tom, jak jsou samotná data organizována a ukládána. Přeskočíme zde několik úrovní – například metaslab – abychom nezanesli detaily a zároveň zachovali pochopení celkové struktury.
Dataset
Když poprvé vytvoříme datovou sadu, zobrazí se veškerý dostupný prostor fondu. Poté nastavíme kvótu - a změníme bod připojení. Kouzlo!
Zvol je z větší části jen datová sada zbavená své vrstvy souborového systému, kterou zde nahrazujeme naprosto normálním souborovým systémem ext4.
Datová sada ZFS je zhruba stejná jako standardní připojený souborový systém. Stejně jako běžný souborový systém na první pohled vypadá jako „jen další složka“. Ale stejně jako běžné připojitelné souborové systémy má každá datová sada ZFS svou vlastní sadu základních vlastností.
Za prvé, datová sada může mít přiřazenou kvótu. Pokud je nastaveno zfs set quota=100G poolname/datasetname, pak nebudete moci zapisovat do připojené složky /poolname/datasetname více než 100 GiB.
Všimli jste si přítomnosti – a absence – lomítek na začátku každého řádku? Každá datová sada má své vlastní místo v hierarchii ZFS i v hierarchii systémového připojení. V hierarchii ZFS není žádné úvodní lomítko – začínáte názvem fondu a pak cestou od jedné datové sady k další. Například, pool/parent/child pro datovou sadu s názvem child pod nadřazenou datovou sadou parent v bazénu s kreativním názvem pool.
Ve výchozím nastavení bude bod připojení datové sady ekvivalentní jejímu názvu v hierarchii ZFS s úvodním lomítkem – fond s názvem pool namontován jako /pool, datový soubor parent namontovaný v /pool/parenta podřízenou datovou sadu child namontovaný v /pool/parent/child. Bod připojení systému datové sady však lze změnit.
Pokud upřesníme zfs set mountpoint=/lol pool/parent/childa poté datovou sadu pool/parent/child namontovaný na systému jako /lol.
Kromě datasetů bychom měli zmínit objemy (zvols). Svazek je zhruba stejný jako datová sada, kromě toho, že ve skutečnosti nemá systém souborů – je to pouze blokové zařízení. Můžete např. tvořit zvol Se jménem mypool/myzvol, pak jej naformátujte pomocí souborového systému ext4 a poté připojte tento souborový systém – nyní máte souborový systém ext4, ale se všemi bezpečnostními funkcemi ZFS! To se může zdát hloupé na jednom počítači, ale mnohem větší smysl to dává jako backend při exportu zařízení iSCSI.
Bloky
Soubor je reprezentován jedním nebo více bloky. Každý blok je uložen na jednom virtuálním zařízení. Velikost bloku se obvykle rovná parametru záznamová velikost, ale lze snížit na 2^ směnapokud obsahuje metadata nebo malý soubor.
My opravdu doopravdy nedělat si legraci o obrovském trestu za výkon, pokud nastavíte příliš malý posun
Ve fondu ZFS jsou všechna data včetně metadat uložena v blocích. Maximální velikost bloku pro každou sadu dat je definována ve vlastnosti recordsize (velikost záznamu). Velikost záznamu lze změnit, ale nezmění se tím velikost ani umístění žádných bloků, které již byly zapsány do datové sady – ovlivní to pouze nové bloky při jejich zápisu.
Pokud není uvedeno jinak, aktuální výchozí velikost záznamu je 128 kB. Je to trochu ošemetný kompromis, kdy výkon není dokonalý, ale ani ve většině případů není hrozný. Recordsize lze nastavit na libovolnou hodnotu od 4K do 1M (s pokročilým nastavením recordsize můžete nainstalovat ještě více, ale to je zřídka dobrý nápad).
Libovolný blok odkazuje na data pouze jednoho souboru – do jednoho bloku nemůžete nacpat dva různé soubory. Každý soubor se skládá z jednoho nebo více bloků v závislosti na velikosti. Pokud je velikost souboru menší než velikost záznamu, bude uložen v menší velikosti bloku – například blok se souborem o velikosti 2 kB zabere na disku pouze jeden sektor o velikosti 4 kB.
Pokud je soubor dostatečně velký a vyžaduje několik bloků, pak všechny záznamy s tímto souborem budou mít velikost recordsize - včetně posledního záznamu, jehož hlavní část může být .
zvols nemají majetek recordsize — místo toho mají rovnocennou vlastnost volblocksize.
Sektory
Posledním, nejzákladnějším stavebním kamenem je sektor. Je to nejmenší fyzická jednotka, kterou lze zapisovat nebo číst ze základního zařízení. Po několik desetiletí používala většina disků 512bajtové sektory. V poslední době je většina disků nastavena na 4 KiB sektory a některé – zejména SSD – mají 8 KiB sektorů nebo i více.
Systém ZFS má vlastnost, která umožňuje ručně nastavit velikost sektoru. Tato vlastnost ashift. Poněkud matoucí je, že ashift je mocninou dvou. Například, ashift=9 znamená velikost sektoru 2^9 nebo 512 bajtů.
ZFS se dotazuje operačního systému na podrobné informace o každém blokovém zařízení, když je přidáno do nového vdev, a na základě těchto informací teoreticky automaticky nainstaluje ashift správně. Bohužel mnoho disků lže o velikosti svého sektoru, aby byla zachována kompatibilita se systémem Windows XP (který nebyl schopen porozumět diskům s jinými velikostmi sektorů).
To znamená, že správci ZFS důrazně doporučujeme znát skutečnou velikost sektoru svých zařízení a ručně ji nastavit ashift. Pokud je posunutí nastaveno příliš nízko, počet operací čtení/zápisu se astronomicky zvýší. Takže zápis 512bajtových „sektorů“ do skutečného 4 KiB sektoru znamená, že musíte napsat první „sektor“, poté přečíst 4 KiB sektor, upravit jej druhým 512-bytovým „sektorem“ a zapsat jej zpět do nového 4 KiB sektor atd. pro každý záznam.
V reálném světě takový postih postihuje SSD Samsung EVO, za což ashift=13, ale tyto SSD lžou o velikosti svého sektoru, a proto je výchozí nastavení nastaveno na ashift=9. Pokud zkušený správce systému toto nastavení nezmění, pak tento SSD funguje pomalejší konvenční magnetický HDD.
Pro srovnání pro příliš velkou velikost ashift neexistuje prakticky žádná pokuta. Neexistuje žádná skutečná penalizace za výkon a nárůst nevyužitého prostoru je nekonečně malý (nebo nulový s povolenou kompresí). Proto důrazně doporučujeme nainstalovat i ty jednotky, které používají 512bajtové sektory ashift=12 nebo ashift=13čelit budoucnosti s důvěrou.
Vlastnost ashift je nastaven pro každé virtuální zařízení vdev a ne pro bazén, jak se mnozí mylně domnívají – a po instalaci se nemění. Pokud se náhodou trefíte ashift když do bazénu přidáte nový vdev, nenávratně jste tento bazén znečistili zařízením s nízkým výkonem a obvykle nezbývá nic jiného, než bazén zničit a začít znovu. Ani odstranění vdev vás nezachrání před nefunkční konfigurací ashift!
Mechanismus kopírování při zápisu
Pokud běžný souborový systém potřebuje přepsat data, změní každý blok tam, kde se nachází
Souborový systém kopírování při zápisu zapíše novou verzi bloku a poté odemkne starou verzi
Stručně řečeno, pokud ignorujeme skutečné fyzické umístění bloků, pak se naše „datová kometa“ zjednoduší na „datového červa“, který se pohybuje zleva doprava po mapě dostupného prostoru.
Nyní můžeme získat dobrou představu o tom, jak fungují snímky kopírování při zápisu – každý blok může patřit k více snímkům a bude přetrvávat, dokud nebudou zničeny všechny související snímky.
Mechanismus Copy on Write (CoW) je základním základem toho, co dělá ZFS tak úžasným systémem. Základní koncept je jednoduchý – pokud požádáte tradiční souborový systém o změnu souboru, udělá přesně to, co jste požadovali. Pokud požádáte souborový systém s kopírováním při zápisu, aby udělal totéž, řekne „ok“, ale bude vám lhát.
Místo toho souborový systém kopírování při zápisu zapíše novou verzi upraveného bloku a poté aktualizuje metadata souboru, aby odpojil starý blok a přiřadil k němu nový blok, který jste právě napsali.
Odpojení starého bloku a propojení nového se provádí v rámci jedné operace, takže jej nelze přerušit – pokud se poté vypnete, máte novou verzi souboru, a pokud vypnete předčasně, máte starou verzi . V žádném případě nedojde ke konfliktům v systému souborů.
Kopírování při zápisu v ZFS probíhá nejen na úrovni souborového systému, ale také na úrovni správy disků. To znamená, že ZFS není ovlivněn bílým místem () - jev, kdy se proužek stačil nahrát pouze částečně, než došlo k pádu systému, s poškozením pole po restartu. Zde je proužek napsán atomicky, vdev je vždy sekvenční a .
ZIL: Protokol záměrů ZFS
Systém ZFS zachází se synchronními zápisy zvláštním způsobem – dočasně, ale okamžitě je ukládá do ZIL, než je později zapíše trvale spolu s asynchronními zápisy.
Data zapsaná do ZIL se obvykle znovu nepřečtou. Ale je to možné po pádu systému
SLOG neboli sekundární LOG zařízení je jen speciální - a pokud možno velmi rychlý - vdev, kde lze ZIL uložit odděleně od hlavního úložiště
Po havárii se všechna špinavá data v ZIL přehrají - v tomto případě je ZIL na SLOG, takže se přehrají odtud
Existují dvě hlavní kategorie operací zápisu – synchronní (synchronizace) a asynchronní (asynchronní). U většiny úloh je naprostá většina zápisů asynchronní – souborový systém umožňuje jejich agregaci a vydávání v dávkách, což snižuje fragmentaci a výrazně zvyšuje propustnost.
Synchronizované nahrávky jsou úplně jiná věc. Když aplikace požaduje synchronní zápis, sdělí to systému souborů: „Musíte to odevzdat do energeticky nezávislé paměti právě teďdo té doby nemůžu nic jiného dělat." Proto by synchronní zápisy měly být na disk potvrzeny okamžitě – a pokud to zvýší fragmentaci nebo sníží propustnost, pak ano.
ZFS zpracovává synchronní zápisy jinak než běžné souborové systémy – místo toho, aby je okamžitě odevzdal do běžného úložiště, ZFS je odevzdá do speciální úložné oblasti zvané ZFS Intent Log nebo ZIL. Trik je v tom, že tyto záznamy také zůstávají v paměti, jsou agregovány spolu s normálními požadavky na asynchronní zápis, aby byly později vyprázdněny do úložiště jako naprosto normální TXG (Transaction Groups).
V normálním provozu se ZIL zapisuje a už se nikdy nečte. Když se po několika okamžicích záznamy ze ZIL ukládají do hlavního úložiště v běžných TXG z RAM, jsou od ZIL odpojeny. Jediný okamžik, kdy se něco čte ze ZIL, je při importu fondu.
Pokud ZFS selže – zhroucení operačního systému nebo výpadek napájení – zatímco jsou v ZIL data, budou tato data načtena při příštím importu fondu (například při restartování nouzového systému). Cokoli v ZIL bude načteno, seskupeno do TXG, odevzdáno do hlavního úložiště a poté odpojeno od ZIL během procesu importu.
Jedna z pomocných tříd vdev se nazývá LOG nebo SLOG, sekundární zařízení LOG. Má to jeden účel - poskytnout fondu samostatný a pokud možno mnohem rychlejší vdev velmi odolný proti zápisu pro uložení ZIL, namísto ukládání ZIL v hlavním úložišti vdev. Samotný ZIL se chová stejně bez ohledu na to, kde je uložen, ale pokud má LOG vdev velmi vysoký výkon zápisu, synchronní zápisy budou rychlejší.
Přidání vdev s LOG do fondu nefunguje nemůže zlepšit výkon asynchronního zápisu – i když vynutíte všechny zápisy do ZIL pomocí zfs set sync=always, budou stále propojeny s hlavním úložištěm v TXG stejným způsobem a stejným tempem jako bez protokolu. Jediným přímým zlepšením výkonu je latence synchronních zápisů (protože rychlejší protokol urychluje operace). sync).
V prostředí, které již vyžaduje mnoho synchronních zápisů, však vdev LOG může nepřímo urychlit asynchronní zápisy a čtení bez mezipaměti. Přesunutí záznamů ZIL do samostatného vdev LOG znamená méně sporů o IOPS na primárním úložišti, což do určité míry zlepšuje výkon všech čtení a zápisů.
Snímky
Mechanismus kopírování při zápisu je také nezbytným základem pro atomické snímky ZFS a přírůstkovou asynchronní replikaci. Aktivní souborový systém má strom ukazatelů označující všechny záznamy aktuálními daty – když pořídíte snímek, jednoduše vytvoříte kopii tohoto stromu ukazatelů.
Když je záznam přepsán v aktivním systému souborů, ZFS nejprve zapíše novou verzi bloku do nevyužitého prostoru. Poté odpojí starou verzi bloku od aktuálního systému souborů. Ale pokud nějaký snímek odkazuje na starý blok, stále zůstává nezměněn. Starý blok nebude ve skutečnosti obnoven jako volné místo, dokud nebudou zničeny všechny snímky odkazující na tento blok!
Replikace
Moje knihovna Steam v roce 2015 měla 158 GiB a zahrnovala 126 927 souborů. To se dost blíží optimální situaci pro rsync – replikace ZFS po síti byla „jen“ o 750 % rychlejší.
Ve stejné síti je replikace jednoho 40GB souboru s obrazem virtuálního stroje Windows 7 úplně jiný příběh. Replikace ZFS je 289krát rychlejší než rsync – nebo „pouze“ 161krát rychlejší, pokud jste dostatečně důvtipní na to, abyste zavolali rsync pomocí --inplace.
Když je obraz virtuálního počítače škálován, rsync s ním škáluje. 1,9 TiB není tak velký pro moderní obraz virtuálního počítače – ale je dostatečně velký na to, aby replikace ZFS byla 1148krát rychlejší než rsync, a to i s argumentem --inplace rsync
Jakmile pochopíte, jak snímky fungují, mělo by být snadné pochopit podstatu replikace. Vzhledem k tomu, že snímek je pouze strom ukazatelů na záznamy, vyplývá z toho, že pokud ano zfs send snímek, pak odešleme jak tento strom, tak všechny záznamy s ním spojené. Když to pošleme zfs send в zfs receive na cíl zapíše jak skutečný obsah bloku, tak i strom ukazatelů, které odkazují na bloky na cílovou datovou sadu.
Ve druhém jsou věci ještě zajímavější zfs send. Nyní máme dva systémy, z nichž každý obsahuje poolname/datasetname@1a pořídíte nový snímek poolname/datasetname@2. Proto v původním bazénu máte datasetname@1 и datasetname@2, a v cílovém fondu zatím pouze první snímek datasetname@1.
Protože máme společný snímek mezi zdrojem a cílem datasetname@1, dokážeme to přírůstkové zfs send přes to. Když říkáme systému zfs send -i poolname/datasetname@1 poolname/datasetname@2, porovnává dva ukazatele stromů. Jakékoli ukazatele, které existují pouze v @2, samozřejmě odkazují na nové bloky - takže potřebujeme obsah těchto bloků.
Na vzdáleném systému zpracování přírůstku send stejně jednoduché. Nejprve zapíšeme všechny nové položky obsažené ve streamu senda poté na tyto bloky přidejte ukazatele. Voila, máme @2 v novém systému!
Asynchronní přírůstková replikace ZFS je obrovským zlepšením oproti dřívějším metodám, které nejsou založeny na snímku, jako je rsync. V obou případech se přenesou pouze změněná data – nejdříve však musí rsync РїСЂРѕС ‡ РёСР ° ССЊ z disku všechna data na obou stranách zkontrolovat součet a porovnat ho. Naproti tomu replikace ZFS nečte nic jiného než strom ukazatelů – a všechny bloky, které nejsou přítomny ve sdíleném snímku.
Vestavěná komprese
Mechanismus kopírování při zápisu také zjednodušuje systém inline komprese. V tradičním souborovém systému je komprese problematická – stará verze i nová verze upravených dat jsou umístěny ve stejném prostoru.
Pokud vezmeme v úvahu kus dat uprostřed souboru, který začíná život jako megabajt nul od 0x00000000 a tak dále, je velmi snadné jej zkomprimovat do jednoho sektoru na disku. Co se ale stane, když tento megabajt nul nahradíme megabajtem nestlačitelných dat, jako je JPEG nebo pseudonáhodný šum? Tento megabajt dat si nečekaně vyžádá ne jeden, ale 256 4 KiB sektorů a na tomto místě na disku je vyhrazen pouze jeden sektor.
ZFS tento problém nemá, protože upravené záznamy se vždy zapisují do nevyužitého místa - původní blok zabírá pouze jeden sektor 4 kB a nový záznam zabere 256, ale to není problém - nedávno upravený fragment z " middle" souboru by byl zapsán do nevyužitého prostoru bez ohledu na to, zda se jeho velikost změnila nebo ne, takže pro ZFS je to zcela běžná situace.
Nativní komprese ZFS je ve výchozím nastavení zakázána a systém nabízí připojitelné algoritmy – aktuálně LZ4, gzip (1-9), LZJB a ZLE.
- LZ4 je streamovací algoritmus, který nabízí extrémně rychlou kompresi a dekompresi a výkonnostní výhody pro většinu případů použití – dokonce i na poměrně pomalých CPU.
- GZIP je úctyhodný algoritmus, který všichni uživatelé Unixu znají a milují. Lze jej implementovat s úrovněmi komprese 1-9, přičemž kompresní poměr a využití procesoru se zvyšují, jak se blíží úrovni 9. Algoritmus je vhodný pro všechny případy použití textu (nebo jiných vysoce komprimovatelných), ale jinak často způsobuje problémy s procesorem – použijte jej opatrně, zejména na vyšších úrovních.
- LZJB je původní algoritmus v ZFS. Je zastaralý a neměl by se dále používat, LZ4 ho předčí ve všech směrech.
- ZLE - kódování nulové úrovně, kódování nulové úrovně. Vůbec se nedotýká normálních dat, ale komprimuje velké sekvence nul. Užitečné pro zcela nekomprimovatelné datové sady (jako JPEG, MP4 nebo jiné již komprimované formáty), protože ignoruje nekomprimovatelná data, ale komprimuje nevyužité místo ve výsledných záznamech.
Kompresi LZ4 doporučujeme téměř pro všechny případy použití; penalizace výkonu při setkání s nestlačitelnými daty je velmi malá a růst výkon pro typická data je významný. Kopírování obrazu virtuálního stroje pro novou instalaci operačního systému Windows (čerstvě nainstalovaný OS, uvnitř ještě žádná data) s compression=lz4 prošel o 27 % rychleji než s compression=noneV .
ARC - adaptivní náhradní mezipaměť
ZFS je jediný moderní souborový systém, o kterém víme, že používá svůj vlastní mechanismus ukládání do mezipaměti pro čtení, místo aby se spoléhal na mezipaměť stránek operačního systému k ukládání kopií nedávno přečtených bloků v paměti RAM.
Ačkoli nativní mezipaměť není bez problémů - ZFS nemůže reagovat na nové požadavky na přidělení paměti tak rychle jako jádro, takže nová výzva malloc() při alokaci paměti může selhat, pokud potřebuje RAM aktuálně obsazenou ARC. Ale existují dobré důvody, proč používat vlastní cache, alespoň prozatím.
Všechny známé moderní operační systémy, včetně MacOS, Windows, Linux a BSD, používají k implementaci mezipaměti stránky algoritmus LRU (nejméně nedávno použité). Jedná se o primitivní algoritmus, který po každém čtení posouvá blok uložený v mezipaměti „nahoru ve frontě“ a podle potřeby posouvá bloky „dolů ve frontě“ za účelem přidání nových chyb v mezipaměti (bloků, které měly být načteny z disku, nikoli z mezipaměti) nahoru.
Algoritmus obvykle funguje dobře, ale na systémech s velkými pracovními datovými sadami LRU snadno vede k thrashingu – vytlačování často potřebných bloků, aby se vytvořilo místo pro bloky, které už nikdy nebudou načteny z mezipaměti.
je mnohem méně naivní algoritmus, který lze považovat za „váženou“ mezipaměť. Pokaždé, když je blok uložený v mezipaměti přečten, je o něco „těžší“ a je těžší jej vyřadit – a to i po vyjmutí bloku sledované v určitém časovém období. Blok, který byl vyřazen, ale pak je třeba jej načíst zpět do mezipaměti, bude také „těžší“.
Konečným výsledkem toho všeho je mezipaměť s mnohem vyšším poměrem zásahů, poměrem mezi zásahy do mezipaměti (čtení provedená z mezipaměti) a vynecháním mezipaměti (čtení z disku). Jedná se o mimořádně důležitou statistiku – nejen že jsou samotné zásahy do mezipaměti obsluhovány řádově rychleji, ale také mohou být rychleji obsloužena vyrovnávací paměť, protože čím více je vyrovnávací paměť, tím méně souběžných požadavků na disk a tím nižší je latence u zbývajících chyb. který musí být podáván s diskem.
Závěr
Poté, co se naučíte základní sémantiku ZFS – jak funguje kopírování při zápisu, stejně jako vztahy mezi fondy úložiště, virtuálními zařízeními, bloky, sektory a soubory – jsme připraveni diskutovat o skutečném výkonu s reálnými čísly.
V další části se podíváme na skutečný výkon poolů se zrcadlenými vdevs a RAIDz navzájem proti sobě a také proti tradičním topologiím RAID jádra Linuxu, které jsme prozkoumali. .
Nejprve jsme chtěli pokrýt pouze základy – samotné topologie ZFS – ale poté takový připravme se na rozhovor o pokročilejším nastavení a ladění ZFS, včetně použití pomocných typů vdev, jako jsou L2ARC, SLOG a Special Allocation.
Zdroj: www.habr.com