{"id":83582,"date":"2020-06-01T19:42:21","date_gmt":"2020-06-01T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost"},"modified":"2020-06-01T19:42:21","modified_gmt":"2020-06-01T17:42:21","slug":"osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Podstawy ZFS: system przechowywania i wydajno\u015b\u0107","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Podstawy
\n
\nNa wiosn\u0119 om\u00f3wili\u015bmy ju\u017c kilka wprowadzaj\u0105cych temat\u00f3w, takich jak jak sprawdzi\u0107 pr\u0119dko\u015b\u0107 swoich dysk\u00f3w<\/a><\/noindex> i czym jest RAID<\/a><\/noindex>. W drugim z nich obiecali\u015bmy nawet kontynuowa\u0107 badanie wydajno\u015bci r\u00f3\u017cnych topologii wielodyskowych w ZFS. To system plik\u00f3w nowej generacji, kt\u00f3ry obecnie wdra\u017cany jest wsz\u0119dzie: od Apple<\/a><\/noindex> do Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nC\u00f3\u017c, dzisiaj jest najlepszy dzie\u0144, aby pozna\u0107 ZFS, drodzy czytelnicy. Po prostu pami\u0119tajcie, \u017ce wed\u0142ug skromnej oceny tw\u00f3rcy OpenZFS, Matta Arenza, \u201eto naprawd\u0119 skomplikowane\u201d.<\/p>\n

Ale zanim przejdziemy do liczb \u2014 a te b\u0119d\u0105, obiecuj\u0119 \u2014 dotycz\u0105cych wszystkich opcji o\u015bmiodyskowej konfiguracji ZFS, trzeba porozmawia\u0107 o tym, jak<\/i> jak ZFS operuje na danych na dysku.<\/p>\n

Zpool, vdev i device<\/h1>\n

\n\"Podstawy
\nTen diagram pe\u0142nego puli obejmuje trzy pomocnicze vdev'y, po jednym z ka\u017cdej klasy, oraz cztery dla RAIDz2.<\/i><\/p>\n

\"Podstawy
\nZwykle nie ma powod\u00f3w, aby tworzy\u0107 pul z niezgodnych typ\u00f3w i rozmiar\u00f3w vdev \u2013 ale je\u015bli chcesz, nic nie stoi na przeszkodzie, aby to zrobi\u0107<\/i><\/p>\n

Aby naprawd\u0119 zrozumie\u0107 system plik\u00f3w ZFS, musisz dok\u0142adnie przyjrze\u0107 si\u0119 jego rzeczywistej strukturze. Po pierwsze, ZFS \u0142\u0105czy tradycyjne poziomy zarz\u0105dzania wolumenami i systemem plik\u00f3w. Po drugie, stosuje transakcyjny mechanizm kopiowania przy zapisie. Te cechy oznaczaj\u0105, \u017ce system strukturalnie r\u00f3\u017cni si\u0119 bardzo od zwyk\u0142ych system\u00f3w plik\u00f3w i macierzy RAID. Pierwszym zestawem podstawowych budulc\u00f3w do zrozumienia jest: pul storage (zpool), wirtualne urz\u0105dzenie (vdev) i rzeczywiste urz\u0105dzenie (device).<\/p>\n

zpool<\/h3>\n

\nPul storage zpool to najwy\u017csza struktura ZFS. Ka\u017cdy pul zawiera jedno lub wi\u0119cej wirtualnych urz\u0105dze\u0144. Z kolei ka\u017cde z nich zawiera jedno lub wi\u0119cej rzeczywistych urz\u0105dze\u0144 (device). Wirtualne pule to autonomiczne bloki. Jeden fizyczny komputer mo\u017ce zawiera\u0107 dwa lub wi\u0119cej oddzielnych pu\u0142k\u00f3w, ale ka\u017cdy jest ca\u0142kowicie niezale\u017cny od innych. Puli nie mog\u0105 wsp\u00f3\u0142dzieli\u0107 wirtualnych urz\u0105dze\u0144.<\/p>\n

Nadwy\u017cka ZFS wyst\u0119puje na poziomie wirtualnych urz\u0105dze\u0144, a nie na poziomie pu\u0142\u00f3w. Na poziomie pu\u0142\u00f3w nie ma absolutnie \u017cadnej nadwy\u017cki \u2014 je\u015bli kt\u00f3rekolwiek urz\u0105dzenie vdev lub specjalne vdev zostanie utracone, ca\u0142y pul zostanie utracony.<\/p>\n

Nowoczesne pule storage mog\u0105 przetrwa\u0107 utrat\u0119 pami\u0119ci podr\u0119cznej lub dziennika urz\u0105dzenia wirtualnego \u2014 chocia\u017c mog\u0105 straci\u0107 niewielk\u0105 ilo\u015b\u0107 nieczystych danych, je\u015bli utrac\u0105 dziennik vdev podczas awarii zasilania lub systemu.<\/p>\n

Panuje powszechne nieporozumienie, \u017ce \u201epasy danych\u201d (stripy) ZFS s\u0105 zapisywane w ca\u0142ej puli. To nieprawda. Zpool to wcale nie ciekawy RAID0, to raczej co\u015b bardziej interesuj\u0105cego. JBOD<\/a><\/noindex> z\u0142o\u017conym zmiennym mechanizmem dystrybucji.<\/p>\n

W wi\u0119kszo\u015bci przypadk\u00f3w zapisy s\u0105 rozk\u0142adane mi\u0119dzy dost\u0119pne urz\u0105dzenia wirtualne w zale\u017cno\u015bci od dost\u0119pnej przestrzeni, tak \u017ce teoretycznie wszystkie b\u0119d\u0105 nape\u0142niane r\u00f3wnocze\u015bnie. W p\u00f3\u017aniejszych wersjach ZFS uwzgl\u0119dniono bie\u017c\u0105ce wykorzystanie (utilizacj\u0119) vdev \u2014 je\u015bli jedno urz\u0105dzenie wirtualne jest znacznie bardziej obci\u0105\u017cone ni\u017c inne (na przyk\u0142ad z powodu obci\u0105\u017cenia podczas odczytu), zostanie tymczasowo pomini\u0119te przy zapisie, mimo \u017ce ma najwy\u017cszy wsp\u00f3\u0142czynnik dost\u0119pnej przestrzeni.<\/p>\n

Mechanizm okre\u015blania wykorzystania wbudowany w nowoczesne metody dystrybucji zapis\u00f3w ZFS mo\u017ce zmniejszy\u0107 op\u00f3\u017anienia i zwi\u0119kszy\u0107 przepustowo\u015b\u0107 w okresach nietypowo wysokiego obci\u0105\u017cenia \u2014 ale to nie dawanie carte blanche<\/i> na niezamierzone mieszanie wolnych HDD i szybkich SSD w jednej puli. Taka nier\u00f3wna pula b\u0119dzie nadal pracowa\u0107 z pr\u0119dko\u015bci\u0105 najwolniejszego urz\u0105dzenia, jak gdyby by\u0142a ca\u0142kowicie z\u0142o\u017cona z takich urz\u0105dze\u0144.<\/p>\n

vdev<\/h3>\n

\nKa\u017cda pula storage sk\u0142ada si\u0119 z jednego lub kilku urz\u0105dze\u0144 wirtualnych (virtual device, vdev). Z kolei ka\u017cde vdev zawiera jedno lub kilka rzeczywistych urz\u0105dze\u0144. Wi\u0119kszo\u015b\u0107 urz\u0105dze\u0144 wirtualnych jest u\u017cywana do prostego przechowywania danych, ale istnieje kilka pomocniczych klas vdev, w tym CACHE, LOG i SPECIAL. Ka\u017cdy z tych typ\u00f3w vdev mo\u017ce mie\u0107 jedn\u0105 z pi\u0119ciu topologii: urz\u0105dzenie pojedyncze (single-device), RAIDz1, RAIDz2, RAIDz3 lub lustro (mirror).<\/p>\n

RAIDz1, RAIDz2 i RAIDz3 to specjalne rodzaje tego, co starsi nazywaliby RAID-em o podw\u00f3jnej (przek\u0105tnej) parzysto\u015bci. 1, 2 i 3 odnosz\u0105 si\u0119 do liczby blok\u00f3w parzysto\u015bci przydzielonych dla ka\u017cdej grupy danych. Zamiast oddzielnych dysk\u00f3w do zapewnienia parzysto\u015bci, wirtualne urz\u0105dzenia RAIDz rozk\u0142adaj\u0105 t\u0119 parzysto\u015b\u0107 p\u00f3\u0142jednostajnie na dyskach. Zestaw RAIDz mo\u017ce straci\u0107 tyle dysk\u00f3w, ile ma blok\u00f3w parzysto\u015bci; je\u015bli straci jeszcze jeden, ulegnie awarii i zabierze ze sob\u0105 pul\u0119 pami\u0119ci.<\/p>\n

W lustrzanych wirtualnych urz\u0105dzeniach (mirror vdev) ka\u017cdy blok jest przechowywany na ka\u017cdym urz\u0105dzeniu w vdev. Chocia\u017c najcz\u0119\u015bciej wyst\u0119puj\u0105 podw\u00f3jne lustra (two-wide), w lustrze mo\u017ce by\u0107 dowolna liczba urz\u0105dze\u0144 \u2014 w du\u017cych instalacjach, aby zwi\u0119kszy\u0107 wydajno\u015b\u0107 odczytu i odporno\u015b\u0107 na awarie, cz\u0119sto stosuje si\u0119 potr\u00f3jne. Lustro vdev mo\u017ce przetrwa\u0107 ka\u017cd\u0105 awari\u0119, o ile przynajmniej jedno urz\u0105dzenie w vdev dzia\u0142a.<\/p>\n

Pojedyncze vdev z definicji s\u0105 niebezpieczne. Takie wirtualne urz\u0105dzenie nie przetrwa \u017cadnej awarii \u2014 i je\u015bli jest u\u017cywane jako magazyn lub specjalne vdev, jego awaria spowoduje zniszczenie ca\u0142ej puli. B\u0105d\u017a tutaj bardzo, bardzo ostro\u017cny.<\/p>\n

Wirtualne urz\u0105dzenia CACHE, LOG i SPECIAL mog\u0105 by\u0107 tworzone w dowolnej z powy\u017cszych topologii \u2014 ale pami\u0119taj, \u017ce utrata wirtualnego urz\u0105dzenia SPECIAL oznacza utrat\u0119 puli, dlatego zdecydowanie zaleca si\u0119 zastosowanie topologii nadmiarowej.<\/p>\n

urz\u0105dzenie<\/h3>\n

\nPrawdopodobnie to naj\u0142atwiejszy do zrozumienia termin w ZFS \u2014 to dos\u0142ownie blokowe urz\u0105dzenie dost\u0119pu losowego. Pami\u0119taj, \u017ce wirtualne urz\u0105dzenia sk\u0142adaj\u0105 si\u0119 z oddzielnych urz\u0105dze\u0144, a pula jest zbudowana z wirtualnych urz\u0105dze\u0144.<\/p>\n

Dyski \u2014 magnetyczne lub p\u00f3\u0142przewodnikowe \u2014 s\u0105 najcz\u0119\u015bciej u\u017cywanymi blokowymi urz\u0105dzeniami, kt\u00f3re s\u0142u\u017c\u0105 jako budulce vdev. Jednak ka\u017cdy urz\u0105dzenie z deskryptorem w \/dev nadaje si\u0119 \u2014 wi\u0119c jako oddzielne urz\u0105dzenia mo\u017cna u\u017cy\u0107 ca\u0142ych sprz\u0119towych zestaw\u00f3w RAID.<\/p>\n

Prosty plik raw jest jednym z najwa\u017cniejszych alternatywnych blokowych urz\u0105dze\u0144, z kt\u00f3rych mo\u017ce by\u0107 zbudowane vdev. Testowe pule z plik\u00f3w sparse<\/a><\/noindex>\u00a0to bardzo wygodny spos\u00f3b na testowanie polece\u0144 puli oraz sprawdzanie, ile miejsca jest dost\u0119pne w puli lub w wirtualnym urz\u0105dzeniu danej topologii.<\/p>\n

\"Podstawy
\nMo\u017cesz utworzy\u0107 testowy pul z rozproszonych plik\u00f3w w zaledwie kilka sekund \u2014 ale nie zapomnij potem usun\u0105\u0107 ca\u0142ego pulu i jego komponent\u00f3w.<\/i> <\/p>\n

Za\u0142\u00f3\u017cmy, \u017ce chcesz zainstalowa\u0107 serwer z o\u015bmioma dyskami i planujesz u\u017cy\u0107 dysk\u00f3w o pojemno\u015bci 10 TB (~9300 GiB) \u2014 ale nie jeste\u015b pewien, kt\u00f3ra topologia najlepiej odpowiada Twoim potrzebom. W powy\u017cszym przyk\u0142adzie budujemy testowy pul z rozproszonych plik\u00f3w w kilka sekund \u2014 i teraz wiemy, \u017ce RAIDz2 vdev z o\u015bmioma dyskami po 10 TB zapewnia 50 TiB u\u017cytecznej pojemno\u015bci.<\/p>\n

Kolejn\u0105 szczeg\u00f3ln\u0105 klas\u0105 urz\u0105dze\u0144 s\u0105 SPARE (rezerwowe). Urz\u0105dzenia hot-swappable, w przeciwie\u0144stwie do zwyk\u0142ych urz\u0105dze\u0144, nale\u017c\u0105 do ca\u0142ego pulu, a nie do jednego wirtualnego urz\u0105dzenia. Je\u015bli jakie\u015b vdev w pulu zawodzi, a rezerwowe urz\u0105dzenie jest pod\u0142\u0105czone i dost\u0119pne, automatycznie do\u0142\u0105czy do uszkodzonego vdev.<\/p>\n

Po pod\u0142\u0105czeniu do uszkodzonego vdev rezerwowe urz\u0105dzenie zaczyna otrzymywa\u0107 kopie lub rekonstrukcje danych, kt\u00f3re powinny by\u0107 na brakuj\u0105cym urz\u0105dzeniu. W tradycyjnym RAID nazywa si\u0119 to odbudow\u0105 (rebuilding), a w ZFS to \u00abodtwarzanie nadmiaru\u00bb (resilvering).<\/p>\n

Wa\u017cne jest, aby pami\u0119ta\u0107, \u017ce rezerwowe urz\u0105dzenia nie zast\u0119puj\u0105 na sta\u0142e uszkodzonych urz\u0105dze\u0144. To tylko tymczasowe zast\u0119pstwo w celu skr\u00f3cenia czasu, w kt\u00f3rym vdev jest w stanie degradacji. Po tym, jak administrator wymieni uszkodzone urz\u0105dzenie vdev, nast\u0119puje odbudowa nadmiaru na to sta\u0142e urz\u0105dzenie, a SPARE od\u0142\u0105cza si\u0119 od vdev i wraca do pracy jako rezerwowe dla ca\u0142ego pulu.<\/p>\n

Zbiory danych, bloki i sektory<\/h1>\n

\nNast\u0119pnym zestawem element\u00f3w, kt\u00f3re nale\u017cy zrozumie\u0107 w naszej podr\u00f3\u017cy po ZFS, nie s\u0105 tak bardzo sprz\u0119tem, jak tym, jak dane s\u0105 zorganizowane i przechowywane. Pomijamy tu kilka poziom\u00f3w \u2014 takich jak metaslab \u2014 aby nie przyt\u0142acza\u0107 szczeg\u00f3\u0142ami, zachowuj\u0105c zrozumienie og\u00f3lnej struktury.<\/p>\n

Zbi\u00f3r danych (dataset)<\/h3>\n

\n\"Podstawy
\nGdy po raz pierwszy tworzymy zbi\u00f3r danych, pokazuje on ca\u0142kowit\u0105 dost\u0119pn\u0105 przestrze\u0144 pulu. Nast\u0119pnie ustalamy kwot\u0119 \u2014 i zmieniamy punkt montowania. Magia!<\/i> <\/p>\n

\"Podstawy
\nZvol to w zasadzie po prostu zbi\u00f3r danych pozbawiony swojego poziomu systemu plik\u00f3w, kt\u00f3ry zast\u0119pujemy tutaj ca\u0142kowicie normalnym systemem plik\u00f3w ext4.<\/i> <\/p>\n

Zestaw danych ZFS jest w przybli\u017ceniu analogiczny do standardowego zamontowanego systemu plik\u00f3w. Tak jak typowy system plik\u00f3w, na pierwszy rzut oka wydaje si\u0119 by\u0107 \u201epo prostu kolejnym folderem\u201d. Jednak podobnie jak w przypadku typowych zamontowanych system\u00f3w plik\u00f3w, ka\u017cdy zestaw danych ZFS ma w\u0142asny zestaw podstawowych w\u0142a\u015bciwo\u015bci.<\/p>\n

Przede wszystkim, zestaw danych mo\u017ce mie\u0107 przydzielon\u0105 kwot\u0119. Je\u015bli ustawisz zfs set quota=100G poolname\/datasetname<\/code>, to nie b\u0119dziesz m\u00f3g\u0142 zapisywa\u0107 w zamontowanym folderze \/poolname\/datasetname<\/code> wi\u0119cej ni\u017c 100 GiB.<\/p>\n

Zauwa\u017cy\u0142e\u015b obecno\u015b\u0107 \u2014 i brak \u2014 uko\u015bnik\u00f3w na pocz\u0105tku ka\u017cdej linii? Ka\u017cdy zestaw danych ma swoje miejsce zar\u00f3wno w hierarchii ZFS, jak i w hierarchii montowania systemu. W hierarchii ZFS nie ma wiod\u0105cego uko\u015bnika \u2014 zaczynasz od nazwy puli, a nast\u0119pnie przechodzisz od jednego zestawu danych do nast\u0119pnego. Na przyk\u0142ad, pool\/parent\/child<\/code> dla zestawu danych o nazwie child<\/code> pod rodzicem zestawu danych parent<\/code> w puli o kreatywnej nazwie pool<\/code>.<\/p>\n

Domy\u015blnie, punkt montowania zestawu danych b\u0119dzie r\u00f3wny jego nazwie w hierarchii ZFS, z uko\u015bnikiem na pocz\u0105tku \u2014 pula o nazwie pool<\/code> zamontowana jako \/pool<\/code>, zestaw danych parent<\/code> zamontowany w \/pool\/parent<\/code>, a zestaw danych podrz\u0119dny child<\/code> zamontowany w \/pool\/parent\/child<\/code>. Jednak punkt montowania zestawu danych w systemie mo\u017cna zmieni\u0107.<\/p>\n

Je\u015bli okre\u015blimy zfs set mountpoint=\/lol pool\/parent\/child<\/code>, to zestaw danych pool\/parent\/child<\/code> b\u0119dzie zamontowany w systemie jako \/lol<\/code>.<\/p>\n

Opr\u00f3cz zestaw\u00f3w danych, musimy wspomnie\u0107 o woluminach (zvols). Wolumin jest w przybli\u017ceniu podobny do zestawu danych, z wyj\u0105tkiem tego, \u017ce nie ma w nim faktycznie systemu plik\u00f3w \u2014 to po prostu urz\u0105dzenie blokowe. Mo\u017cesz, na przyk\u0142ad, utworzy\u0107 zvol<\/code> z nazw\u0105 mypool\/myzvol<\/code>, a nast\u0119pnie sformatowa\u0107 je z systemem plik\u00f3w ext4, a nast\u0119pnie zamontowa\u0107 ten system plik\u00f3w \u2014 teraz masz system plik\u00f3w ext4, ale z obs\u0142ug\u0105 wszystkich funkcji zabezpiecze\u0144 ZFS! Mo\u017ce si\u0119 to wydawa\u0107 g\u0142upie na jednym komputerze, ale ma znacznie wi\u0119cej sensu jako backend przy eksportowaniu urz\u0105dzenia iSCSI.<\/p>\n

Bloki<\/h3>\n

\n\"Podstawy
\nPlik jest reprezentowany przez jeden lub kilka blok\u00f3w. Ka\u017cdy blok jest przechowywany na jednym wirtualnym urz\u0105dzeniu. Rozmiar bloku jest zazwyczaj r\u00f3wny parametrowi recordsize<\/b>, ale mo\u017ce by\u0107 zmniejszony do 2^ashift<\/b>, je\u015bli zawiera metadane lub ma\u0142y plik.<\/i><\/p>\n

\"Podstawy
\nRzeczywi\u015bcie, naprawd\u0119<\/b> nie \u017cartujemy o ogromnym spadku wydajno\u015bci, je\u015bli ustawisz zbyt ma\u0142y ashift.<\/i><\/p>\n

W puli ZFS wszystkie dane, w tym metadane, s\u0105 przechowywane w blokach. Maksymalny rozmiar bloku dla ka\u017cdego zbioru danych jest okre\u015blany w w\u0142a\u015bciwo\u015bci recordsize<\/code> (rozmiar rekordu). Rozmiar rekordu mo\u017ce si\u0119 zmienia\u0107, ale nie wp\u0142ynie to na rozmiar lub lokalizacj\u0119 jakichkolwiek blok\u00f3w, kt\u00f3re ju\u017c zosta\u0142y zapisane w zbiorze danych \u2014 dzia\u0142a to tylko dla nowych blok\u00f3w w miar\u0119 ich zapisywania.<\/p>\n

Je\u015bli nie okre\u015blono inaczej, bie\u017c\u0105cy rozmiar rekordu domy\u015blnie wynosi 128 KiB. Jest to swoisty, nie\u0142atwy kompromis, w kt\u00f3rym wydajno\u015b\u0107 nie b\u0119dzie idealna, ale r\u00f3wnie\u017c nie b\u0119dzie straszna w wi\u0119kszo\u015bci przypadk\u00f3w. Recordsize<\/code> mo\u017cna ustawi\u0107 na dowoln\u0105 warto\u015b\u0107 od 4K do 1M (z dodatkowymi ustawieniami recordsize<\/code> mo\u017cna ustawi\u0107 jeszcze wi\u0119cej, ale rzadko jest to dobrym pomys\u0142em).<\/p>\n

Ka\u017cdy blok odnosi si\u0119 do danych tylko jednego pliku \u2014 nie mo\u017cna wcisn\u0105\u0107 dw\u00f3ch r\u00f3\u017cnych plik\u00f3w w jeden blok. Ka\u017cdy plik sk\u0142ada si\u0119 z jednego lub kilku blok\u00f3w, w zale\u017cno\u015bci od rozmiaru. Je\u015bli rozmiar pliku jest mniejszy ni\u017c rozmiar rekordu, zostanie zapisany w bloku mniejszego rozmiaru \u2014 na przyk\u0142ad blok z plikiem 2 KiB zajmie tylko jeden sektor 4 KiB na dysku.<\/p>\n

W woluminach zvol nie ma w\u0142a\u015bciwo\u015bci recordsize<\/code>\u00a0\u2014 zamiast tego maj\u0105 ekwiwalentn\u0105 w\u0142a\u015bciwo\u015b\u0107 volblocksize<\/code>.<\/p>\n

Sektory<\/h3>\n

\nOstatnim, najbardziej podstawowym budulcem s\u0105 sektory. To najmniejsza fizyczna jednostka, kt\u00f3ra mo\u017ce by\u0107 zapisana lub odczytana z podstawowego urz\u0105dzenia. Przez kilka dziesi\u0119cioleci w wi\u0119kszo\u015bci dysk\u00f3w stosowano sektory o rozmiarze 512 bajt\u00f3w. W ostatnich czasach wi\u0119kszo\u015b\u0107 dysk\u00f3w zosta\u0142a skonfigurowana na sektory 4 KiB, a w niekt\u00f3rych \u2014 szczeg\u00f3lnie SSD \u2014 sektory 8 KiB lub nawet wi\u0119ksze.<\/p>\n

W systemie ZFS istnieje w\u0142a\u015bciwo\u015b\u0107, kt\u00f3ra pozwala r\u0119cznie ustawi\u0107 rozmiar sektora. Ta w\u0142a\u015bciwo\u015b\u0107 ashift<\/code>. Nieco zagmatwane jest to, \u017ce ashift jest pot\u0119g\u0105 liczby dwa. Na przyk\u0142ad, ashift=9<\/code> oznacza rozmiar sektora 2^9, czyli 512 bajt\u00f3w.<\/p>\n

ZFS prosi system operacyjny o szczeg\u00f3\u0142owe informacje o ka\u017cdym urz\u0105dzeniu blokowym, gdy jest ono dodawane do nowego vdev, i teoretycznie automatycznie ustawia ashift w zale\u017cno\u015bci od tych informacji. Niestety, wiele dysk\u00f3w k\u0142amie na temat rozmiaru swojego sektora, aby zachowa\u0107 zgodno\u015b\u0107 z Windows XP (kt\u00f3ry nie potrafi\u0142 obs\u0142ugiwa\u0107 dysk\u00f3w o innych rozmiarach sektor\u00f3w).<\/p>\n

Oznacza to, \u017ce administrator ZFS musi zna\u0107 rzeczywisty rozmiar sektora swoich urz\u0105dze\u0144 i r\u0119cznie ustawia\u0107 ashift<\/code>. Je\u015bli ustawiony zostanie zbyt ma\u0142y ashift, to astronomicznie wzrasta liczba operacji odczytu\/zapisu. Tak wi\u0119c zapis 512-bajtowych 'sektor\u00f3w' w rzeczywisty sektor 4 KiB oznacza konieczno\u015b\u0107 zapisania pierwszego 'sektora', nast\u0119pnie odczytania sektora 4 KiB, zmodyfikowania go drugim 512-bajtowym 'sektorem', zapisania go z powrotem do nowego sektora 4 KiB i tak dalej dla ka\u017cdego zapisu.<\/p>\n

W rzeczywistym \u015bwiecie taka kara dotyka dysk\u00f3w SSD Samsung EVO, dla kt\u00f3rych powinien obowi\u0105zywa\u0107 ashift=13<\/code>, ale te SSD k\u0142ami\u0105 na temat rozmiaru swojego sektora, dlatego domy\u015blnie ustawia si\u0119 ashift=9<\/code>. Je\u015bli do\u015bwiadczony administrator systemu nie zmieni tego parametru, to ten SSD dzia\u0142a wolniej<\/i> od zwyk\u0142ego HDD.<\/p>\n

Dla por\u00f3wnania, za zbyt du\u017cy rozmiar ashift<\/code> nie ma praktycznie \u017cadnej kary. Nie ma rzeczywistego spadku wydajno\u015bci, a zwi\u0119kszenie nieu\u017cywanej przestrzeni jest niesko\u0144czenie ma\u0142e (lub r\u00f3wne zeru w przypadku w\u0142\u0105czonego kompresji). Dlatego zdecydowanie zalecamy nawet tym dyskom, kt\u00f3re naprawd\u0119 u\u017cywaj\u0105 512-bajtowych sektor\u00f3w, aby ustawi\u0107 ashift=12<\/code> lub nawet ashift=13<\/code>, aby pewnie patrze\u0107 w przysz\u0142o\u015b\u0107.<\/p>\n

W\u0142a\u015bciwo\u015b\u0107 ashift<\/code> jest ustawiane dla ka\u017cdego wirtualnego urz\u0105dzenia vdev, a nie dla puli<\/i>, jak wielu b\u0142\u0119dnie s\u0105dzi - i nie zmienia si\u0119 po ustawieniu. Je\u015bli przypadkowo zepsujesz ashift<\/code> przy dodawaniu nowego vdev do puli, to bezpowrotnie zanieczy\u015bci\u0142e\u015b t\u0119 pul\u0119 urz\u0105dzeniem o niskiej wydajno\u015bci i najcz\u0119\u015bciej nie ma innego wyj\u015bcia, jak tylko zniszczy\u0107 pul\u0119 i zacz\u0105\u0107 od nowa. Nawet usuni\u0119cie vdev nie uratuje ci\u0119 przed b\u0142\u0119dn\u0105 konfiguracj\u0105. ashift<\/code>!<\/p>\n

Mechanizm kopiowania przy zapisie<\/h3>\n

\n\"Podstawy
\nJe\u015bli zwyk\u0142y system plik\u00f3w musi ponownie zapisa\u0107 dane - zmienia ka\u017cdy blok tam, gdzie si\u0119 znajduje.<\/i><\/p>\n

\"Podstawy
\nSystem plik\u00f3w z kopiowaniem przy zapisie zapisuje now\u0105 wersj\u0119 bloku, a nast\u0119pnie odblokowuje star\u0105 wersj\u0119<\/i><\/p>\n

\"Podstawy
\nW abstrakcyjnym uj\u0119ciu, ignoruj\u0105c rzeczywiste fizyczne rozmieszczenie blok\u00f3w, nasza \u201ekometa danych\u201d upraszcza si\u0119 do \u201erobaka danych\u201d, kt\u00f3ry porusza si\u0119 od lewej do prawej po mapie dost\u0119pnej przestrzeni<\/i><\/p>\n

\"Podstawy
\nTeraz mo\u017cemy dobrze zrozumie\u0107, jak dzia\u0142aj\u0105 migawki kopiowania przy zapisie \u2014 ka\u017cdy blok mo\u017ce nale\u017ce\u0107 do kilku migawek i b\u0119dzie przechowywany, dop\u00f3ki wszystkie zwi\u0105zane migawki nie zostan\u0105 usuni\u0119te<\/i><\/p>\n

Mechanizm kopiowania przy zapisie (Copy on Write, CoW) jest fundamentaln\u0105 podstaw\u0105 tego, co sprawia, \u017ce ZFS jest tak niesamowitym systemem. Podstawowa koncepcja jest prosta \u2014 gdy poprosisz tradycyjny system plik\u00f3w o zmian\u0119 pliku, zrobi dok\u0142adnie to, co powiedzia\u0142e\u015b. Gdy poprosisz system plik\u00f3w z kopiowaniem przy zapisie o to samo, powie 'dobrze' \u2014 ale sk\u0142amie.<\/p>\n

Zamiast tego system plik\u00f3w z kopiowaniem przy zapisie zapisuje now\u0105 wersj\u0119 zmienionego bloku, a nast\u0119pnie aktualizuje metadane pliku, aby zerwa\u0107 powi\u0105zanie ze starym blokiem i powi\u0105za\u0107 go z nowym blokiem, kt\u00f3ry w\u0142a\u015bnie zapisa\u0142e\u015b.<\/p>\n

Od\u0142\u0105czenie starego bloku i powi\u0105zanie nowego odbywa si\u0119 w jednej operacji, wi\u0119c nie mo\u017cna jej przerwa\u0107 \u2014 je\u015bli wy\u0142\u0105czysz zasilanie po jej wykonaniu, masz now\u0105 wersj\u0119 pliku, a je\u015bli wy\u0142\u0105czysz zasilanie wcze\u015bniej, masz star\u0105 wersj\u0119. W ka\u017cdym przypadku w systemie plik\u00f3w nie wyst\u0105pi\u0105 konflikty.<\/p>\n

Kopiowanie przy zapisie w ZFS odbywa si\u0119 nie tylko na poziomie systemu plik\u00f3w, ale tak\u017ce na poziomie zarz\u0105dzania dyskami. Oznacza to, \u017ce ZFS nie jest podatne na dziur\u0119 w zapisie (dziura w RAID<\/a><\/noindex>) \u2014 zjawisko, w kt\u00f3rym pasmo zd\u0105\u017cy\u0142o tylko cz\u0119\u015bciowo zapisa\u0107 przed awari\u0105 systemu, z uszkodzeniem macierzy po ponownym uruchomieniu. Tutaj pasmo jest zapisywane atomowo, vdev jest zawsze sp\u00f3jny, a Bob jest twoim wujem<\/a><\/noindex>.<\/p>\n

ZIL: dziennik zamiar\u00f3w ZFS<\/h3>\n

\n\"Podstawy
\nSystem ZFS obs\u0142uguje synchronizacyjne zapisy w szczeg\u00f3lny spos\u00f3b \u2014 tymczasowo, ale natychmiastowo zapisuje je w ZIL, zanim p\u00f3\u017aniej zapisze je na sta\u0142e wraz z asynchronicznymi zapisami<\/i><\/p>\n

\"Podstawy
\nZazwyczaj dane zapisane w ZIL nigdy wi\u0119cej nie s\u0105 odczytywane. Ale jest to mo\u017cliwe po awarii systemu<\/i><\/p>\n

\"Podstawy
\nSLOG, czyli wt\u00f3rne urz\u0105dzenie LOG, to po prostu specjalny \u2014 i po\u017c\u0105dany, bardzo szybki \u2014 vdev, w kt\u00f3rym ZIL mo\u017ce by\u0107 przechowywane oddzielnie od g\u0142\u00f3wnego magazynu.<\/i><\/p>\n

\"Podstawy
\nPo awarii wszystkie brudne dane w ZIL s\u0105 przywracane \u2014 w tym przypadku ZIL znajduje si\u0119 na SLOG, wi\u0119c s\u0105 przywracane w\u0142a\u015bnie st\u0105d.<\/i><\/p>\n

Istniej\u0105 dwie g\u0142\u00f3wne kategorie operacji zapisu \u2014 synchroniczne (sync) i asynchroniczne (async). Dla wi\u0119kszo\u015bci obci\u0105\u017ce\u0144 roboczych przyt\u0142aczaj\u0105ca wi\u0119kszo\u015b\u0107 operacji zapisu jest asynchroniczna \u2014 system plik\u00f3w pozwala na agregacj\u0119 i wydawanie ich w pakietach, co zmniejsza fragmentacj\u0119 i znacznie zwi\u0119ksza przepustowo\u015b\u0107.<\/p>\n

Zapisy synchroniczne to zupe\u0142nie inna sprawa. Kiedy aplikacja \u017c\u0105da zapisu synchronicznego, m\u00f3wi systemowi plik\u00f3w: \u201eMusisz to zapisa\u0107 w pami\u0119ci nieulotnej, tej chwili<\/i>, a przez to nie mog\u0119 zrobi\u0107 nic wi\u0119cej\u201d. Dlatego zapisy synchroniczne musz\u0105 by\u0107 natychmiast potwierdzane na dysku \u2014 i je\u015bli to zwi\u0119ksza fragmentacj\u0119 lub zmniejsza przepustowo\u015b\u0107, tak po prostu musi by\u0107.<\/p>\n

ZFS obs\u0142uguje zapisy synchroniczne inaczej ni\u017c zwyk\u0142e systemy plik\u00f3w \u2014 zamiast natychmiast wprowadza\u0107 je do zwyk\u0142ego magazynu, ZFS zapisuje je w specjalnym obszarze pami\u0119ci zwanym dziennikiem zamiar\u00f3w ZFS \u2014 ZFS Intent Log, czyli ZIL. Sztuczka polega na tym, \u017ce te zapisane tak\u017ce<\/i> pozostaj\u0105 w pami\u0119ci, b\u0119d\u0105c agregowanymi razem z normalnymi asynchronicznymi zapytaniami o zapis, aby p\u00f3\u017aniej zosta\u0142y zrzucane do magazynu jako ca\u0142kowicie normalne TXG (grupy transakcji, Transaction Groups).<\/p>\n

W normalnym trybie pracy ZIL jest zapisywane i nigdy wi\u0119cej nie odczytywane. Kiedy po kilku chwilach zapisy z ZIL s\u0105 zapisywane w g\u0142\u00f3wnym magazynie w zwyk\u0142ych TXG z pami\u0119ci operacyjnej, s\u0105 od\u0142\u0105czane od ZIL. Jedynym momentem, kiedy co\u015b jest odczytywane z ZIL, jest przy imporcie puli.<\/p>\n

Je\u015bli wyst\u0105pi awaria ZFS \u2014 awaria systemu operacyjnego lub przerwa w zasilaniu \u2014 gdy w ZIL znajduj\u0105 si\u0119 dane, te dane zostan\u0105 odczytane podczas nast\u0119pnego importu puli (na przyk\u0142ad, przy ponownym uruchamianiu awaryjnego systemu). Wszystko, co znajduje si\u0119 w ZIL, zostanie odczytane, scalone w grupy TXG, zapisane w g\u0142\u00f3wnym magazynie, a nast\u0119pnie od\u0142\u0105czone od ZIL w procesie importu.<\/p>\n

Jedna z pomocniczych klas vdev nazywa si\u0119 LOG lub SLOG, wt\u00f3rne urz\u0105dzenie LOG. Jej zadaniem jest zapewnienie puli oddzielnym, a co wa\u017cniejsze, znacznie szybszym, o bardzo wysokiej odporno\u015bci na zapisy, urz\u0105dzeniem vdev do przechowywania ZIL, zamiast przechowywa\u0107 ZIL na g\u0142\u00f3wnym magazynie vdev. Sam ZIL dzia\u0142a tak samo niezale\u017cnie od miejsca przechowywania, lecz je\u017celi vdev z LOG ma bardzo wysok\u0105 wydajno\u015b\u0107 zapisu, synchrone zapisy b\u0119d\u0105 nast\u0119powa\u0107 szybciej.<\/p>\n

Dodanie vdev z LOG do puli nie mo\u017ce nie potrafi<\/b> poprawi\u0107 wydajno\u015bci asynchronicznego zapisu \u2013 nawet je\u015bli wymuszasz wszystkie zapisy w ZIL za pomoc\u0105 zfs set sync=always<\/code>, nadal b\u0119d\u0105 one zwi\u0105zane z g\u0142\u00f3wnym magazynem w TXG w ten sam spos\u00f3b i w tym samym tempie, co bez dziennika. Jedynym bezpo\u015brednim poprawieniem wydajno\u015bci jest op\u00f3\u017anienie zapisu synchronizacyjnego (poniewa\u017c wi\u0119ksza szybko\u015b\u0107 dziennika przyspiesza realizacj\u0119 operacji. sync<\/code>).<\/p>\n

Jednak w \u015brodowisku, kt\u00f3re ju\u017c wymaga du\u017cej liczby zapis\u00f3w synchronizacyjnych, vdev LOG mo\u017ce po\u015brednio przyspieszy\u0107 asynchroniczny zapis i niebuforowane odczyty. Przeniesienie zapis\u00f3w ZIL do oddzielnego vdev LOG oznacza mniejsz\u0105 konkurencj\u0119 o IOPS w g\u0142\u00f3wnym magazynie, co w pewnym stopniu zwi\u0119ksza wydajno\u015b\u0107 wszystkich operacji odczytu i zapisu.<\/p>\n

Zrzuty<\/h3>\n

\nMechanizm kopiowania przy zapisie tak\u017ce jest niezb\u0119dn\u0105 podstaw\u0105 dla atomowych momen\u0301ta\u0328alnych zrzut\u00f3w ZFS i inkrementalnej asynchronicznej replikacji. W aktywnej systemie plik\u00f3w istnieje drzewo wska\u017anik\u00f3w, kt\u00f3re zaznacza wszystkie zapisy z bie\u017c\u0105cymi danymi \u2013 gdy tworzysz zrzut, po prostu tworzysz kopi\u0119 tego drzewa wska\u017anik\u00f3w.<\/p>\n

Kiedy w aktywnej systemie plik\u00f3w zapisywana jest nowa wersja, ZFS najpierw zapisuje now\u0105 wersj\u0119 bloku w nieu\u017cywanej przestrzeni. Nast\u0119pnie od\u0142\u0105cza star\u0105 wersj\u0119 bloku od obecnej systemu plik\u00f3w. Ale je\u017celi jaki\u015b zrzut odnosi si\u0119 do starego bloku, wci\u0105\u017c pozostaje on niezmienny. Stary blok faktycznie nie b\u0119dzie uznawany za woln\u0105 przestrze\u0144, dop\u00f3ki wszystkie zrzuty odnosz\u0105ce si\u0119 do tego bloku nie zostan\u0105 zniszczone!<\/p>\n

Replikacja<\/h3>\n

\n\"Podstawy
\nMoja biblioteka Steam w 2015 roku zajmowa\u0142a 158 GiB i zawiera\u0142a 126 927 plik\u00f3w. To do\u015b\u0107 blisko optymalnej sytuacji dla rsync \u2013 replikacja ZFS przez sie\u0107 by\u0142a \u201etylko\u201d 750% szybsza.<\/i><\/p>\n

\"Podstawy
\nW tej samej sieci replikacja jednego 40-gigabajtowego pliku obrazu maszyny wirtualnej Windows 7 to zupe\u0142nie inna historia. Replikacja ZFS zachodzi 289 razy szybciej ni\u017c rsync - lub \"zaledwie\" 161 razy szybciej, je\u015bli wystarczaj\u0105co si\u0119 znasz, aby wywo\u0142a\u0107 rsync z kluczem --inplace.<\/i><\/p>\n

\"Podstawy
\nGdy obraz maszyny wirtualnej si\u0119 skalowa\u0142, problemy z rsync r\u00f3wnie\u017c si\u0119 skaluj\u0105. Rozmiar 1,9 TiB nie jest taki du\u017cy dla wsp\u00f3\u0142czesnego obrazu maszyny wirtualnej - ale jest wystarczaj\u0105co du\u017cy, aby replikacja ZFS okaza\u0142a si\u0119 1148 razy szybsza ni\u017c rsync, nawet z argumentem rsync --inplace.<\/i><\/p>\n

Gdy ju\u017c zrozumiesz, jak dzia\u0142aj\u0105 migawki, \u0142atwo b\u0119dzie uchwyci\u0107 istot\u0119 replikacji. Poniewa\u017c migawka to po prostu drzewo wska\u017anik\u00f3w do rekord\u00f3w, oznacza to, \u017ce je\u015bli robimy zfs send<\/code> migawk\u0119, to wysy\u0142amy zar\u00f3wno to drzewo, jak i wszystkie zwi\u0105zane z nim rekordy. Kiedy przesy\u0142amy to zfs send<\/code> do zfs receive<\/code> do docelowego obiektu, zapisuje on zar\u00f3wno rzeczywist\u0105 zawarto\u015b\u0107 bloku, jak i drzewo wska\u017anik\u00f3w odwo\u0142uj\u0105cych si\u0119 do blok\u00f3w w docelowym zbiorze danych.<\/p>\n

Wszystko staje si\u0119 jeszcze ciekawsze na drugim zfs send<\/code>. Teraz mamy dwa systemy, z kt\u00f3rych ka\u017cdy zawiera poolname\/datasetname@1<\/code>, a ty robisz now\u0105 migawk\u0119 poolname\/datasetname@2<\/code>. Dlatego w pierwotnym pulu masz datasetname@1<\/code> i datasetname@2<\/code>, a w docelowym pulu na razie tylko pierwsz\u0105 migawk\u0119. datasetname@1<\/code>.<\/p>\n

Poniewa\u017c mi\u0119dzy \u017ar\u00f3d\u0142em a celem mamy wsp\u00f3ln\u0105 migawk\u0119 datasetname@1<\/code>, mo\u017cemy zrobi\u0107 inkrementaln\u0105<\/i> zfs send<\/code> na jej podstawie. Kiedy m\u00f3wimy systemowi zfs send -i poolname\/datasetname@1 poolname\/datasetname@2<\/code>, por\u00f3wnuje ono dwa drzewa wska\u017anik\u00f3w. Jakiekolwiek wska\u017aniki, kt\u00f3re istniej\u0105 tylko w @2<\/code>, oczywi\u015bcie, odnosz\u0105 si\u0119 do nowych blok\u00f3w \u2014 dlatego potrzebujemy zawarto\u015bci tych blok\u00f3w.<\/p>\n

W zdalnym systemie przetwarzanie inkrementalne send<\/code> jest r\u00f3wnie proste. Najpierw zapisujemy wszystkie nowe rekordy zawarte w strumieniu send<\/code>, a nast\u0119pnie dodajemy wska\u017aniki do tych blok\u00f3w. Voil\u00e0, mamy to @2<\/code> w nowym systemie!<\/p>\n

Asynchroniczna replikacja inkrementalna ZFS to ogromne ulepszenie w por\u00f3wnaniu do wcze\u015bniejszych metod, kt\u00f3re nie opiera\u0142y si\u0119 na migawkach, takich jak rsync. W obu przypadkach przekazywane s\u0105 tylko zmienione dane \u2014 ale rsync musi najpierw przeczyta\u0107<\/i> przeczyta\u0107 wszystkie dane z obu stron, aby sprawdzi\u0107 sum\u0119 i por\u00f3wna\u0107 j\u0105. W przeciwie\u0144stwie do tego, replikacja ZFS nie odczytuje nic poza drzewami wska\u017anik\u00f3w \u2014 oraz jakichkolwiek blok\u00f3w, kt\u00f3re nie s\u0105 reprezentowane w wsp\u00f3lnej migawce.<\/p>\n

Wbudowane kompresje<\/h3>\n

\nMechanizm kopiowania podczas zapisu r\u00f3wnie\u017c upro\u015bci\u0142 system wbudowanej kompresji. W tradycyjnych systemach plik\u00f3w kompresja jest problematyczna \u2014 zar\u00f3wno stara wersja, jak i nowa wersja zmienionych danych znajduj\u0105 si\u0119 w tej samej przestrzeni.<\/p>\n

Je\u015bli rozwa\u017cymy fragment danych w \u015brodku pliku, kt\u00f3ry zaczyna swoje \u017cycie jako megabajt zer od 0x00000000 i tak dalej \u2014 \u0142atwo go skompresowa\u0107 do jednego sektora na dysku. Ale co si\u0119 stanie, je\u015bli zamienimy ten megabajt zer na megabajt nieskompresowanych danych, takich jak JPEG lub pseudolosowy szum? Niespodziewanie ten megabajt danych b\u0119dzie potrzebowa\u0142 nie jednego, a 256 sektor\u00f3w po 4 KiB, a w tym miejscu na dysku zarezerwowany jest tylko jeden sektor.<\/p>\n

ZFS nie ma tego problemu, poniewa\u017c zmienione wpisy s\u0105 zawsze zapisywane w nieu\u017cywanej przestrzeni \u2014 oryginalny blok zajmuje tylko jeden sektor 4 KiB, a nowy wpis zajmie 256, ale to nie jest problem \u2014 niedawno zmieniony fragment z \"\u015brodka\" pliku by\u0142by zapisany w nieu\u017cywanej przestrzeni, niezale\u017cnie od tego, czy zmieni\u0142 swoj\u0105 wielko\u015b\u0107, wi\u0119c dla ZFS to ca\u0142kowicie normalna sytuacja.<\/p>\n

Wbudowana kompresja ZFS jest domy\u015blnie wy\u0142\u0105czona, a system oferuje programowalne algorytmy \u2014 obecnie w\u015br\u00f3d nich s\u0105 LZ4, gzip (1-9), LZJB i ZLE.<\/p>\n

Je\u015bli plik jest wystarczaj\u0105co du\u017cy i wymaga kilku blok\u00f3w, wszystkie zapisy tego pliku b\u0119d\u0105 mia\u0142y rozmiar recordsize<\/code>\u00a0\u2014 w tym ostatni zapis, kt\u00f3rego g\u0142\u00f3wna cz\u0119\u015b\u0107 mo\u017ce okaza\u0107 si\u0119 nieu\u017cywan\u0105 przestrzeni\u0105<\/a><\/noindex>.<\/p>\n