Pojemność w ZFS RAID

1. Pojemność w ZFS RAID wyjaśnienie

ZFS RAID nie przypomina tradycyjnego RAID. Jego struktura na dysku jest znacznie bardziej wyrafinowana niż w przypadku starszej implementacji RAID i zawiera szeroką gamę funkcji ochrony danych. Ponieważ struktura dyskowa jest bardziej niezawodna, przewidywanie, ile użytecznej pojemności uzyskasz z zestawu dysków twardych o danym układzie vdev (skrót od urządzenia wirtualnego) jest bardziej złożone. Istnieją warstwy kosztów ogólnych związanych z ochroną danych, które należy zrozumieć i uwzględnić, aby uzyskać dokładne oszacowanie. Najlepszym sposobem na zapoznanie się z narzutem alokacji ZFS jest przejrzenie przykładu i zrozumieć pojemność w ZFS RAID

Zacznijmy od wybrania niezbyt idealnego układu vdev RAIDZ, abyśmy mogli zobaczyć wpływ wszystkich różnych form obciążenia ZFS. Kiedy zrozumiemy RAIDZ, zrozumienie lustrzanych i paskowych vdevów będzie proste. Będziemy używać dysków 14 x 18 TB w dwóch 7-szerokich serwerach RAIDZ2 (7w22) vdev. Ogólnie rzecz biorąc, łatwiej będzie nam pracować w bajtach, więc nie musimy się martwić o konwersję między TB i TiB.

Zaczynając od pojemności poszczególnych dysków, odejmiemy rozmiar partycji wymiany. Partycja wymiany działa jako rozszerzenie puli pamięci fizycznej systemu. Jeśli działający proces potrzebuje więcej pamięci niż jest aktualnie dostępna, system może wyładować część danych znajdujących się w pamięci do przestrzeni wymiany. Domyślnie TrueNAS tworzy partycję wymiany o wielkości 2 GiB na każdym dysku w puli danych. Inne produkty korzystające z ZFS mogą tworzyć większą lub mniejszą partycję wymiany lub mogą w ogóle jej nie tworzyć.

18 1000 ^ 4 – 2 1024 ^ 3 = 17997852516352 bytes

Następnie chcemy uwzględnić zarezerwowane sektory na początku dysku. Układ i rozmiar tych zarezerwowanych sektorów będzie zależał od systemu operacyjnego i schematu partycji, ale w tym przykładzie użyjemy FreeBSD i GPT, ponieważ tego właśnie używają TrueNAS CORE i Enterprise. Wyrównanie sektorów możemy sprawdzić uruchamiając listę gpart na jednym z dysków w puli:

root @ truenas [ – ] # gpart list dal
Geom name : dal
modified : false
state : OK
fwheads : 255
Ewsectors : 63
last : 35156249959
first : 40
entries : 128
scheme : GPT
Providers :

1. Name : dalpl
Mediasize : 2147483648 ( 2.0G )
Sectorsize : 512
Stripesize : 0
Stripeoffset : 65536
Mode : r0w0e0
efimedia: HD (1, GPI, b1c018 8e – b098-11ec – 8907-0800275344ce, 0x80, 0x400000)
rawuuid: blc0188e – b098-11ec – 89c7-0800275344ce
rawtype: 516e7cb5-6ecf – 11d6-8ff8-00022d09712b
label: ( null )
length: 2147483648
offset: 65536
type: freebsd – awap

index : 1
end : 4194431
start : 128
2. Name : dalp2
Mediasize : 17997852430336 ( 16 )
Sectorsize : 512
Stripesize : 0
Stripeoffset : 2147549184
Mode : rlwle2
efimedia : HD ( 2 , GPT , b215c5ef – b098-11ec – 8907-0800275344ce , 0x400080 , 0x82139ce8 )
rawuuid : b215c5ef – b098-11ec – 89c7-0800275344ce
rawtype : 516e7cba – 6ecf – 11d6-8ff8-00022409712b
label : ( null )
length : 17997852430336
offset : 2147549184
type : freebsd – zfs
index : 2
end : 35156249959
start : 4194432
Consumers :
1. Name : dal
Mediasize : 18000000000000 ( 161 )
Sectorsize : 512
Mode : rlwle3
index : 1
end : 4194431
start : 128
2. Name : dalp2
Mediasize : 17997852430336 ( 16 )
Sectorsize : 512
Stripesize : 0
Stripeoffset : 2147549184
Mode : rlwle2
efimedia : HD ( 2 , GPT , b215c5ef – b098-11ec – 8907-0800275344ce , 0x400080 , 0x82139ce8 )
rawuuid : b215c5ef – b098-11ec – 89c7-0800275344ce
rawtype : 516e7cba – 6ecf – 11d6-8ff8-00022409712b
label : ( null )
length : 17997852430336
offset : 2147549184
type : freebsd – zfs
index : 2
end : 35156249959
start : 4194432
Consumers :
1. Name : dal
Mediasize : 18000000000000 ( 161 )
Sectorsize : 512
Mode : rlwle3

Po pierwsze, należy pamiętać, że rozmiar sektora używanego na tym dysku wynosi 512 bajtów. Pierwszym blokiem logicznym na tym dysku jest właściwie sektor 40; To oznacza, że odjęto 40 * 512 = 20480 bajtów.

Sekcja 1. Nazwa: dalp1 opisuje partycję wymiany na tym dysku. Widzimy, że ma rozmiar 2 GiB (zgodnie z oczekiwaniami)
i zaczyna się od adresu bloku logicznego 128 (tj. przesunięcia 512 * 128 = 65536 bajtów). Jeśli odejmiemy tę przestrzeń
z oczekiwanego rozmiaru partycji obliczonego powyżej widzimy, że pokrywa się on z rzeczywistym rozmiarem partycji na dysku:

17997852516352 – 20480 – 65536 = 17997852430336 bytes

Zanim ZFS zrobi cokolwiek z tą partycją, zaokrągla jej rozmiar w dół, aby dopasować go do bloku 256 KiB. Ten zaokrąglony rozmiar jest określany w kodzie ZFS jako osize lub rozmiar woluminu fizycznego dysku.

floor (17997852430336 / (256 * 1024)) – 256 * 1024 = 17997852311552 bytes

Wewnątrz woluminu fizycznego ZFS musimy uwzględnić specjalne etykiety dodane do każdego dysku. ZFS tworzy 4 kopie etykiety vdev o rozmiarze 256 KiB na każdym dysku (2 na początku partycji ZFS i 2 na końcu) plus osadzony plik rozruchowy o pojemności 3,5 MiB region modułu ładującego. Szczegóły dotyczące funkcji etykiet vdev można znaleźć tutaj, a szczegóły dotyczące rozmiaru i rozmieszczenia etykiet można znaleźć tutaj oraz w sekcjach tuż poniżej (linie 541 i 548). Odejmujemy to 4,5 MiB (4* 256K1B + 3,5M1B) przestrzeni od partycji ZFS, aby uzyskać jej „użyteczny” rozmiar:

17997852311552 – 4 * 262144- 3670016 = 17997847592960 bytes

Następnie musimy obliczyć rozmiar alokacji lub „rozmiar” całego vdev. Po prostu mnożymy użyteczną partycję ZFS rozmiar według szerokości vdev tutaj. Nie uwzględniamy jeszcze przestrzeni parzystości:

17997847592960 + 7 = 125984933150720 bytes

To około 114,58 TIB. ZFS bierze tę część pamięci reprezentowaną przez rozmiar alokacji i dzieli ją na mniejsze, wiadra o jednakowych rozmiarach zwane „metaslabami”: ZFS tworzy te metaslaby, ponieważ są znacznie łatwiejsze w zarządzaniu niż pełny rozmiar vdev podczas śledzenia używanej i dostępnej przestrzeni za pomocą map kosmicznych. Rozmiar metaslab jest kontrolowany głównie przez zmienną metaslab shift lub ma_shift, przy czym docelowy rozmiar wynosi 2 bajty ms_shift.

Więcej na temat wymiarowania metaslabów możesz przeczytać tutaj. ZFS ustawia ms_shift tak, aby ilość metaslabs była mniejsza niż 200. ms_shift zaczyna się od 29 i rośnie aż do 34.

Kiedy ms_shift osiągnie wartość 34 , nie będzie już większa, ale zamiast tego liczba metaslabów przekroczy 200. Przy wartości ms_shift równej 34 ZFS utworzy tyle metaslabów o pojemności 16 GB, ile zmieści się w rozmiarze alokacji vdev. 2 ^ 17 lub 131 072 to górna granica liczby metaslabs (lub me_count); po przekroczeniu tego limitu ZFS pozwala na rozbudowę metaslab do rozmiaru przekraczającego 16 GB.

Limit ten nie zostanie osiągnięty, dopóki wielkość alokacji vdev nie wyniesie co najmniej 2017 16 GIB = 2 PIB. Ponownie, jest to wielkość pojedynczego vdev, a nie całej puli; nie spotkasz się z tym, chyba że umieścisz więcej niż 125 dysków 18 TB w jednym vdevie Z2.

Z drugiej strony, granica przejścia od shift=34 do ms_shift=33 jest dość mała, 1600 GiB lub 1,5625 TiB. Innymi słowy, jeśli twoje vdevs nie są mniejsze niż 1,5625 TiB, wartość ms_shift twojego biednego będzie wynosić 34. W naszym przykładzie asize znacznie przekracza 1,5625 TiB, więc mamy ms_shift = 34.
Kiedy już mamy wartość ms_shift, możemy łatwo obliczyć rozmiar metaslabu, wykonując 2 ^ ms_shift .

2 ^ 34 = 17179869184 bytes

Przy ms_shift = 34 rozmiar metaslabu będzie wynosić 16 GiB. Możemy zauważyć, że jeśli ms_shift wynosił 33, rozmiar metaslabu wynosiłby 8 GIB; rozmiar metaslab zmniejsza się o połowę za każdym razem, gdy moje przesunięcie zmniejsza się o 1. Musimy teraz dowiedzieć się, jak to zrobić wiele pełnych metaslabów 16 GIB zmieści się w każdym vdev, więc obliczamy size / metaslab_size i zaokrąglamy w dół za pomocą funkcji Floor() (rozmiar metaslabu 16 GiB jest reprezentowany w bajtach poniżej):

floor ( 125984933150720 / 17179869184 ) = 7333

To daje nam 7333 metaslabów na vdevs. Możemy sprawdzić nasze dotychczasowe postępy na rzeczywistym systemie ZFS za pomocą polecenia zdb dostarczonego przez ZFS. Możemy sprawdzić rozmiar vdev i wartość przesunięcia metaslabu, uruchamiając zdb – Spool_name i możemy sprawdzić liczbę metaslabów, uruchamiając zab -m Spool_name.

Uwaga dotycząca TrueNAS, będziesz musiał dodać opcję -U /data/zfs/zpool.cache

(tj. zdb -U /data/zfs/zpool .cache -C Spool_name i zdb -U /data/zfs/zpool .cache -m Spool_name ).

root @ truenas [ ~ ] # zdb -U /data/zfe/zpool.cache -C tank
version : 5000
MOS Configuration :

name : ‘ tank ‘
state : 0
txg : 11
pool_guid : 758404
errata : 0
hostid : 3601001416
hostname : 37
com.delphix : has_per_vdev_zape
vdev_children : 2
vdev_tree :

type : ‘ root ‘
1d : 0
guid : 758404 )
create_txg : 4
children [ 0 ] =
1111
type : ‘ raidz ‘

1d : 0
1111

guid : 2993118 : 7866813004
nparity : 2
metaslab_array : 268
metaslab shift : 34
ashift : 12
asize : 125984933150720
is_log : 0
create_txg : 4
com.delphix : vdev_zap_top : 129
children [ 0 ] :
type : ‘ disk ‘

… (wyjście obcięte) …

…
root @ truenas [ ~ ] # 2db -U /data/zfe/zpool.cache -m tank
Metaslabs :
vdev 0
metaslabs 7333
metaslab 0
space map object 274 :
amp_length = 0x18
smp_alloc = 0x12000
Flush data :
unflushed txg = 5
metaslab
ms_unflushed_phys object 270
spacemap offset
offset
space map object 273 :
amp_length = 0x18
smp_alloc = 0x21000
Flush data :
unflushed txg – 6
( output truncated ) …
1 offset
0
400000000
spacemap

1 offset
0
400000000
spacemap
Możemy to potwierdzić, uruchamiając zpool list:
spacemap
125979980726272 + 2 = 2519
free
274 free
NAME
tank 251959961452544 1437696 251959960014848
273 free

ZFS rezerwuje jeden metaslab na każdą „normalną klasę” vdev (czyli nie z vdevów z pamięcią podręczną itp.) dla „wbudowanego SLOG”, ale nie jest to uwzględniane w obliczeniach pojemności. Więcej informacji na ten temat tutaj.

2. Obliczanie przestrzeni

Aby obliczyć użyteczną przestrzeń w naszym vdevie, mnożymy rozmiar metaslabu przez liczbę metaslabów. Oznacza to, że przestrzeń w partycji ZFS, która nie jest zajęta przez jedną z metaslabs, nie jest dla nas użyteczna i jest skutecznie tracona. Teoretycznie, używając mniejszej wartości ms_shift, moglibyśmy odzyskać trochę tego miejsca, ale ostatecznie zużylibyśmy dużo więcej pamięci systemowej, więc nie jest to tego warte. Przy 7333 metaslabach przy 16 GIB na metaslab mamy:

17179869184 * 7333 = 125979980726272 bytes

To około 114,58 TiB użytecznej przestrzeni na vdev. Jeśli pomnożymy to przez liczbę vdevów, otrzymamy rozmiar puli ZFS:

1452544 bytes 125979980726272 + 2 = 251

Możemy to potwierdzić, uruchamiając  listę zpool:

root@truenas ( -1 # zpool list -p -o name, size, alloc, free tank

NAME                            SIZE       ALLOC           FREE

tank          251959961452544      1437696         251959960014848

Flaga -p pokazuje dokładne (prasowalne) wartości bajtów, a flaga określa, jakie właściwości będą wyświetlane (bez flagi wyświetla mnóstwo informacji, które nie są dla tego istotne, a tekst tabeli zawija się i staje się prawie nieczytelny).
Zauważ, że wartość zpool SIZE odpowiada wartości obliczonej powyżej. Na razie odłożymy tę liczbę na bok i obliczymy parzystość RAIDZ i dopełnienie. Zanim przejdziemy dalej, pomocne będzie przejrzenie kilku podstaw ZFS, w tym zmiany.
minimalny rozmiar bloku, sposób działania zapisów częściowych i wartość rozmiaru rekordu ZFS.

Dyski twarde i SSD dzielą swoją przestrzeń na maleńkie logiczne segmenty zwane „sektorami”. Sektor ma zwykle 4 KiB, ale może mieć 512 bajtów na starszych dyskach twardych lub 8 KiB na niektórych dyskach SSD. Sektor reprezentuje najmniejszą puszkę odczytu lub zapisu na dysku wykonać w ramach jednej operacji. ZFS śledzi rozmiar sektora dysku jako ashift, gdzie 2 ^ ashift = rozmiar sektora (więc przesunięcie = 9 dla sektorów o wielkości 512 bajtów, 12 dla sektorów o wielkości 4 KiB, 13 dla sektorów o wielkości 8 KiB).

W RAIDZ najmniejszy użyteczny zapis, jaki możemy wykonać, to szerokość sektorów p + 1, gdzie p to poziom parzystości (1 dla RAIDZ1, 2 dla 22, 3 dla Z3).

Daje nam to pojedynczy sektor danych użytkownika i wymaganą liczbę sektorów parzystości do ochrony tych danych użytkownika. Mając to na uwadze, ZFS przydziela miejsce na dyskach vdev RAIDZ w parzystych wielokrotnościach tej wartości p + 1, aby zmaksymalizować pojemność i zapobiec bezużytecznym – małym przerwom na dysku. Na przykład wyobraźmy sobie, że dokonaliśmy zapisu w 5 sektorach do vdev RAIDZ2 (3 sektory danych użytkownika i 2 sektory parytetowe).

Później usuwamy te dane, pozostawiając na dysku 5-sektorową przerwę. Teraz zapisujemy 3-sektorowy zapis do vdev Z2, ląduje on w tej 5-sektorowej luce i mamy 2-sektorową lukę, z którą nie możemy nic zrobić. Tego miejsca nie można odzyskać bez całkowitego przepisania po nim wszystkich pozostałych sektorów na dysku.

Aby tego uniknąć, ZFS uzupełni wszystkie zapisy do vdevów RAIDZ, tak aby były parzystą wielokrotnością tej wartości p + 1. Przez „wypełnienie” rozumiemy, że logicznie rzecz biorąc, zawiera to kilka dodatkowych sektorów w bloku do zapisania, ale w rzeczywistości nic w nich nie zapisuje. Kod źródłowy ZFS określa je jako sektory „pominięte”.

3. Zapis paskowy

W przeciwieństwie do tradycyjnych implementacji RAIDS i RAID6, ZFS obsługuje zapis częściowy. Ma to wiele ważnych zalet, ale wiąże się również z pewnymi konsekwencjami dla obliczeń przestrzeni, które musimy wziąć pod uwagę. Obsługa częściowych zapisów rozłożonych oznacza, że w naszym przykładzie 7wZ2 vdev możemy obsługiwać zapis w sumie 12 sektorów, nawet jeśli 12 nie jest parzystą wielokrotnością szerokości naszego paska (7). Liczba 12 jest równomiernie podzielna przez p + 1 (co w tym przypadku wynosi 3, ponieważ używamy RAIDZ2), więc nie potrzebujemy nawet żadnego dopełnienia. Mielibyśmy pojedynczy pełny pasek składający się z 7 sektorów (2 sektory parzystości plus 5 sektorów danych), po którym następowałby częściowy pasek z 2 sektorami parzystości i 3 sektorami danych. Będzie to ważne, ponieważ chociaż możemy obsługiwać częściowe zapisy rozłożone, każdy pasek (w tym częściowe paski) wymaga pełnego zestawu sektorów z parzystością p.

4. Wartość rozmiaru rekordu

Ostatnią koncepcją ZFS, którą musimy tutaj zrozumieć, jest wartość rozmiaru rekordu. Wartość rozmiaru rekordu ZFS służy do określenia największego bloku danych, jaki ZFS może zapisać. Można go ustawić dla każdego zestawu danych i może mieć dowolną parzystą potęgę 2 od 512 bajtów do 1 MiB. Domyślna wartość rozmiaru rekordu to 128 KiB. Do celów szacowania pojemności ZFS zawsze przyjmuje rekord o wielkości 128 KiB. Należy zauważyć, że ta wartość rozmiaru rekordu uwzględnia tylko dane użytkownika, a nie parzystość czy dopełnienie. Warto również wspomnieć, że rozmiary bloków w ZFS będą się różnić w zależności od tego, ile danych należy zapisać, a wartość rozmiaru rekordu wymusza górną granicę rozmiaru bloku, ale ZFS do obliczenia miejsca przyjmuje wszystkie rekordy o wielkości 128 KB celów, więc będziemy używać tej wartości w przyszłości.

Możesz przeczytać więcej o obsłudze przez ZFS częściowych zapisów rozłożonych i dopełnianiu bloków w artykule Matta Ahrensa.
Wracając do naszego przykładu pojemności, minimalna liczba sektorów została już obliczona powyżej przy p + 1 = 3. Następnie musimy obliczyć, ile sektorów zostanie wypełnionych podczas zapisu rekordu (tutaj 128 KiB).

128 * 1024 / 4096 = 32 sektory

Nasza szerokość paska wynosi 7 dysków, więc możemy obliczyć, ile pasków zajmie ten zapis o wielkości 128 KB. Pamiętaj, że potrzebujemy 2 sektorów parzystości na pasek, więc dzielimy 32 sektory przez 5, ponieważ to jest liczba sektorów danych na pasek:
32 (7-2) = 6,4 pasków

Możemy sobie wyobrazić, jak mogłoby to wyglądać na dyskach (P oznacza sektory parzystości, D oznacza sektory danych):

 

Jak wspomniano powyżej, ten częściowy pasek 0,4 również otrzymuje 2 sektory parzystości, więc mamy 7 pasków danych z parzystością po 2 sektory na pasek, czyli łącznie 14 sektorów parzystości. Mamy teraz 32 sektory danych, 14 sektorów parzystości. Dodając je, otrzymujemy łącznie 46 sektorów dla tego bloku danych. 46 nie jest parzystą wielokrotnością naszej minimalnej liczby sektorów (3), więc musimy dodać 2 sektory dopełniające. Daje to całkowitą liczbę sektorów wynoszącą 48:32 sektory danych, 14 sektorów parzystości i 2 sektory wypełniające.

Uwzględniając sektory dopełniające, tak mógłby wyglądać pełny blok 128 KB na dysku. Narysowałem dwa bloki, więc możesz zobaczyć, jak wyrównanie drugiego bloku zostaje nieco przesunięte, aby uwzględnić częściowy pasek, który napisaliśmy.

X reprezentują sektory dopełniające.

Prawdopodobnie wygląda to dziwnie, ponieważ na początku drugiego bloku mamy jeden sektor parzystości, który po prostu wisi samotnie.
Mimo że nie znajduje się dokładnie w tym samym wierszu co dane, które chroni, nadal zapewnia tę ochronę. ZFS wie, gdzie są zapisywane dane dotyczące parzystości, więc tak naprawdę nie ma znaczenia, do jakiego LBA zostaną zapisane, pod warunkiem, że znajdują się na właściwym dysku.
Możemy obliczyć współczynnik wydajności przechowywania danych, dzieląc nasze 32 sektory danych przez 48 wszystkich sektorów potrzebnych do przechowywania ich na dysku w tym konkretnym układzie vdev.

32 / 48 = 0.66667

ZFS używa czegoś podobnego do tego współczynnika podczas alokacji przestrzeni, ale aby uprościć obliczenia i uniknąć przepełnienia mnożenia i innych dziwnych rzeczy, śledzi ten współczynnik jako ułamek 512. Innymi słowy, aby dokładniej przedstawić, jak ZFS „widzi” on – miejsca na dysku, musimy przekonwertować ułamek 32/48 na najbliższy ułamek 512. Będziemy musieli zaokrąglić w dół, aby w liczniku otrzymać liczbę całkowitą (górną część ułamka). Aby to zrobić, obliczamy:

floor ( 0.66667 * 512 ) / 512 = 0.666015625 = 341 / 512

Ten ułamek 341/512 nazywa się vdev_deflate_ratio i to przez niego pomnożymy obliczony powyżej rozmiar puli, aby otrzymać użyteczną przestrzeń na vdev po parzystości i dopełnieniu. Możesz przeczytać trochę więcej na temat współczynnika vdev_deflat tutaj.

251959961452544 * 0.666015625 = 1678271201792 bytes

Ostatnią rzeczą, na którą musimy zwrócić uwagę, jest przestrzeń SPA. ZFS rezerwuje ostatnią część pojemności puli, „aby mieć pewność, że w puli nie zabraknie całkowicie miejsca z powodu nieuwzględnionych zmian (np. w systemie MOS)”: Zwykle jest to 1/32 użytecznej pojemności puli przy minimalnej wartości 128 MB. OpenZFS 2.0.7 wprowadził także maksymalny limit przestrzeni zapasowej wynoszącej 128GiB (to dobrze; przestrzeń zapasowa była kiedyś OGROMNA w dużych pulach). O rezerwacji przestrzeni SPA przeczytasz tutaj.
W naszym przykładowym basenie miejsce na odpady będzie wyglądało następująco:

167809271201792 * 1 / 32 = 5244039725056 bytes

To 4,77 TiB zarezerwowane na potrzeby SPA i niesamowita inwestycja w ochronę danych i trwałość. Jeśli korzystamy z OpenZFS 2.0.7 lub nowszego, zamiast tego użyjemy 128 GiB:

167809271201792 – 128 1024 ^ 3 = 16767183248320 bytes
= 156156.5625 GiB
= 152.4966 T1B

Jest to całkowita użyteczna pojemność puli 14 dysków 18 TB skonfigurowanych w formacie 2*7wZ2. Obliczenia możemy potwierdzić za pomocą listy zfs:

root @ truenas [ -1 # zfs list -p tank
NAME          USED            REFER                         AVAIL           MOUNT     POINT

tank             1080288         167671831168032      196416         /mnt           /tank

Podobnie jak w przypadku polecenia zpool list, flaga -p pokazuje dokładne wartości bajtów.

167671831168032 + 1080288 = 167671832248320 bytes
= 156156.5625 GiB
= 152.4966 T1B

Dodając wartości USED i AVAIL, możemy potwierdzić, że nasze obliczenia są dokładne.

5. lustrzanych wersji VDev

Lustrzane vdev działają w podobny sposób, ale rozmiar vdev to tylko pojemność pojedynczego dysku (minus etykiety Zfs i tak dalej), a wtedy vdev_deflate_ratio wynosi po prostu 512/512 lub 1.0. Pomijamy wszystkie kwestie związane z parzystością i sektorem dopełniającym, ale nadal musimy uwzględnić alokację metaslabu i przestrzeń zapasową SPA.

W tym przykładzie wykorzystano VirtualBox z wirtualnymi dyskami 18 TB, które mieszczą dokładnie 18 000 000 000 000 bajtów. Prawdziwe dyski nie będą miały tak dokładnej pojemności fizycznej; dyski o pojemności 8 TB w moim systemie TrueNAS mieszczą 8 001 563 222 016 bajtów. Jeśli wykonasz te obliczenia na prawdziwym systemie z dyskami fizycznymi, polecam sprawdzić dokładną pojemność dysku i partycji za pomocą programu gpart lub czegoś podobnego.

6. Kompresja danych i rozmiar bloku

Warto zauważyć, że żadne z tych obliczeń nie uwzględnia kompresji danych. Prawie niemożliwe jest przewidzenie wpływu kompresji na pojemność pamięci bez poddania danych algorytmowi kompresji, którego zamierzasz użyć.
W ix zwykle widzimy redukcję od 1,2:1 do 1,6:1, zakładając przede wszystkim, że dane są kompresowalne.

Ignorujemy również wpływ, jaki zmienne rozmiary bloków będą miały na pojemność puli funkcjonalnej. Użyliśmy bloku 128 KIB, ponieważ jest to ustawienie domyślne ZFS i to, czego używa do obliczeń dostępnej pojemności, ale (jak omówiono powyżej) ZFS może używać innego rozmiaru bloku dla różnych danych. Inny rozmiar bloku zmieni stosunek sektorów danych do sektorów z parzystością i dopełnieniem, więc ogólna wydajność przechowywania może się zmienić.

Powyższy kalkulator umożliwia ustawienie wartości rozmiaru rekordu i obliczenie pojemności w oparciu o pulę pełną bloków o takim rozmiarze. Możesz eksperymentować z różnymi wartościami rozmiaru rekordu, aby sprawdzić ich wpływ na wydajność. Zmiana wartości rozmiaru rekordu zbioru danych będzie miała również wpływ na wydajność, więc przeczytaj o tym przed majsterkowaniem.

Możesz znaleźć dobrą dyskusję na wysokim poziomie na temat dostrajania nagrywania tutaj, bardziej szczegółową dyskusję techniczną tutaj i świetny, ogólny przewodnik dostrajania obciążenia tutaj, na stronie dokumentacji OpenZFS. Można teraz samemu spróbować obliczać pojemność w ZFS RAID

 

Adresy punktów przyjmujących zlecenia można zobaczyć pod tym linkiem “Punkty przyjmowania zleceń“

RAID 50 Data Recovery czyli odzyskiwanie danych z macierzy Raid 50 to zaawansowana usługa oferowana przez MiP Data & Forensic,

posiadająca bardzo bogate doświadczenie w odzyskiwaniu danych z macierzy RAID w Centrum analiz i odzyskiwania danych w Warszawie