Po zakupie nowych dysków zamierzam utworzyć zdegradowaną macierz RAID5 z dwóch dysków (na trzecim na razie znajdują się dane), potem utworzyć wolumen LVM, sformatować go, przekopiować dane z pojedynczego dysku na macierz i dołączyć trzeci dysk do macierzy odbudowując parzystość. Zadanie będzie o tyle ciekawe że dysk ma 4KB sektory i trzeb będzie dbać o wyrównanie zasobu do rozmiaru sektora, a w przypadku LVM’a wyrównanie do chunk’a z macierzy.
Prawidłowe wyrównanie partycji
Kupując nowy dysk (o pojemności od 500GB w górę), mamy spore szanse że trafimy na sztukę, która wykorzystuje 4KB sektory do alokacji danych. Ponieważ statystyczny rozmiar przechowywanych plików rośnie i nawet proste zdjęcie ma powyżej 1MB to wykorzystanie bloków o tym rozmiarze większym niż 512 bajtów jest jak najbardziej uzasadnione - zresztą większość systemów plików i tak wykorzystuje bloki 48KB. Jest tylko jedno ALE: jeżeli nie uwzględnimy tego podczas partycjonowania dysku to sektory 4KB systemu plików zamiast znajdować się w równo w odpowiadających im fizycznych 4KB sektorach dysku - mogą zachodzić na 2 sektory fizyczne - w takiej sytuacji każde odwołanie to takiego sektora w systemie plików wymaga odczytania/zapisanie dwóch sektorów fizycznych. Co prawda w dyskach stosuje się mechanizmy, które powinny zoptymalizować takie sytuacje ale jak potwierdzają benchmarki źle wyrównane partycja mogą znacznie obniżyć wydajność dysku. A jeszcze zabawniej jest jeśli kupimy dysk SSD bo w nich bardzo często fizyczne bloki są 128512KB i żeby było zabawniej to bardzo często dyski SSD deklarują (choćby przez SMART’a) że mają bloki 512B - SIC!
Jeśli mamy fart i nasz dysk raportuje rozmiar fizycznego sektora to możemy to sprawdzić tak:
cat /sys/block/sda/queue/physical_block_size
U mnie to polecenie zwróciło 4096 czyli 4KB co jest zgodne z deklaracją producenta.
Dobre podejście do tematu wyrównania partycji zaproponował Teo Tso czyli wybranie takich parametrów głowic/sektorów na ścieżce by fdisk automatycznie wyrównywał partycje do oczekiwanej przez nas wielkości bloku. Teo proponował użycie 224 głowic i 56 sektorów - co da wyrównanie do 128KB dla wszystkich partycji z wyjątkiem pierwszej (pierwsza będzie wyrównana do 4KB o ile nie wymusimy startu z 256 sektora). Jeżeli mamy dysk z blokami 4KB lub pierwszą partycję zamierzamy wykorzystać jako np. /boot (gdzie wydajność nie ma aż takiego dużego znaczenia) to jest to ok. Ale jeśli kompatybilność z DOS’em mamy w poważaniu to możemy w fdisku utworzyć pierwszą partycję wyrównaną do 128KB lub 1MB.
Przeważnie wolałem cfdiska od fdiska (bo po co się męczyć z topornym interfejsem) ale nie udało mi się skubańca zmusić by tworzył pierwszą partycję w sposób nie kompatybilny z DOS’em. fdisk pomimo toporności po podaniu liczby głowic i sektorów w ścieżce podpowiedział mi poprawne wyrównanie partycji (a gdybyśmy posiadali starszą wersję, która nie jest tak sprytna to przynajmniej możemy podać ręcznie od którego sektora ma zaczynać się partycja).
Wyrównanie do 128KB
fdisk -u -H 224 -S 56 /dev/sdX
Opcja -u zmienia domyślną jednostkę na sektory (mamy wtedy mniejsze liczby, które łatwiej się przelicza). Dla wyrównania do 128KB pierwsza partycja powinna się zaczynać na 256 sektorze. Do wyrównania do 4KB wystarczy zacząć na 56 sektorze (wystarczające przy części nowszych dysków twardych).
Wyrównanie do 1MB
Jeśli jednak dysponujemy dyskiem SSD z ciężko powiedzieć jak dużym blokiem to lepiej wykorzystać wyrównanie do 1MB - zmarnujemy trochę więcej miejsca (tych parę MB jakoś przeżyjemy) ale w tym rozmiarze na pewno zmieści się każdy sektor (a może nawet Erase Block, który obecnie przeważnie ma 512KB choć zdarzają się sztuki z 4MB). Można to osiągnąć z ustawieniem 64 głowic i 32 sektorów na ścieżkę, robimy to tak:
fdisk -u -H 64 -S 32 /dev/sdX
Pierwsza partycja powinna się zaczynać na 2048 sektorze dla wyrównania do 1MB lub 8192 sektorze jeśli chcemy zacząć od 4MB.
Po odpaleniu fdiska z tymi parametrami wybieramy opcję n i lecimy dalej zgodnie z podpowiedziami, np.:
fdisk -u -H 224 -S 56 /dev/sdc
Polecenie (m wyświetla pomoc): <strong>m</strong>
Polecenie
a zmiana flagi rozruchu
b modyfikacja etykiety dysku BSD
c zmiana flagi kompatybilności z DOS-em
d usunięcie partycji
l wypisanie znanych typów partycji
m wyświetlenie tego menu
<strong>n dodanie nowej partycji</strong>
o utworzenie nowej, pustej DOS-owej tablicy partycji
p wypisanie tablicy partycji
q zakończenie bez zapisywania zmian
s utworzenie nowej, pustej etykiety dysku Suna
t zmiana ID systemu partycji
u zmiana jednostek wyświetlania/wprowadzania
v weryfikacja tablicy partycji
w zapis tablicy partycji na dysk i zakończenie
x dodatkowe funkcje (tylko dla ekspertów)
Polecenie (m wyświetla pomoc): <strong>n</strong>
Partition type:
p primary (0 primary, 0 extended, 4 free)
e extended
Select (default <strong>p</strong>):
Using default response p
Numer partycji (1-4, domyślnie <strong>1</strong>):
Przyjęto wartość domyślną 1
Pierwszy sektor (2048-15240575, domyślnie <strong>2048</strong>):
Przyjęto wartość domyślną 2048
Ostatni sektor, +sektorów lub +rozmiar{K,M,G} (2048-15240575, domyślnie 15240575): <strong>+100M</strong>
Polecenie (m wyświetla pomoc): <strong>p</strong>
Dysk /dev/sdc: 7803 MB, bajtów: 7803174912
głowic: 224, sektorów/ścieżkę: 56, cylindrów: 1214, w sumie sektorów: 15240576
Jednostka = sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512
Identyfikator dysku: 0xc3072e18
Urządzenie Rozruch Początek Koniec Bloków ID System
/dev/sdc1 2048 206847 102400 83 Linux
Polecenie (m wyświetla pomoc): <strong>w</strong>
Tablica partycji została zmodyfikowana!
Wywoływanie ioctl() w celu ponownego odczytu tablicy partycji.
UWAGA: ponowny odczyt tablicy partycji zakończył się błędem 16: Urządzenie lub zasoby zajęte.
Jądro nadal używa starej tablicy. Nowa tablica będzie używana po
następnym restarcie systemu albo po uruchomieniu partprobe(8) lub kpartx(8)
Synchronizacja dysków.
P.S. Po co w ogóle partycjonować - można użyć całych urządzeń
Co prawda w przypadku gdy zamierzam całe dyski poświęcić na RAID’a mógłbym ich nie partycjonować tylko użyć całych urządzeń i zadbać tylko by mdadm poprawnie się wyrównał (co zresztą robi automatycznie do 4KB), ale obawiałem się jak względem takich dysków zachowają się inne systemy które mam zainstalowane na komputerze - nie chciałbym aby przypadkiem uznały że to jakiś uszkodzony dysk po czym zainicjowały tablicę partycji… Może to nieuzasadniona fobia ale wiem że względem partycji RAID Autodetect nic takiego mi się nie przytrafi 😃
Tworzenie macierzy RAID
Jak już utworzymy pożądane partycje na pierwszym dysku to musimy je powielić na wszystkich pozostałych dyskach, które zamierzamy włączyć do macierzy - najprościej zrobić to sfdisk’iem:
sfdisk -d /dev/sdX | sfdisk /dev/sdY
Przy czym dysk sdX to źródłowy dysk z gotowymi partycjami, a dysk sdY to każdy na którym chcemy odtworzyć partycje. Można by zrobić na to ładną pętelkę jeśli mamy więcej tych dysków ale celowo tego nie zrobię bo jak znam życie to kiedyś ktoś to skopiuje ze znakiem nowego wiersza i wrzuci do konsoli… 😀
Teraz tworzę zdegradowaną (z dwóch dysków) macierz RAID5… Ale na dobrą sprawę bezpieczniej byłoby utworzyć macierz RAID1 z dwóch dysków (o ile miejsca byłoby wystarczająco na przeniesienie danych) a po przeniesieniu danych na macierz dodanie trzeciego dysku i powiększenie macierzy z reshapingiem do RAID5 - postanowiłem pominąć takie rozwiązanie bo nie bałem się utraty danych, miałem dokładną kopię na innej macierzy 😃
Więc tworzymy macierz:
mdadm --create /dev/md0 --level=5 --raid-devices=2 --chunk=512k /dev/sdX1 /dev/sdY1
Na dobrą sprawę z powyższych opcji tylko chunk nadaje się do “dopasowania” - ja mam zamiar utworzyć macierz z dość dużych zasobów (3x2TB) i przechowywać na niej raczej duże pliki więc 512KB wydaje mi się dobrą wartością. Gdybyśmy jednak potrzebowali większej liczby I/O dla małych pliczków to mniejsza wartość może być lepsza. Warto zrobić kilka benchmarków dla różnych wartości chunk’a i dopasować do przewidywanego przez nas obciążenia.
Aby macierz była widoczne już w czasie startu systemu należy dodatkowo wykonać polecenie:
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
Warto też w pliku /etc/mdadm/mdadm.conf odkomentować i wpisać jakieś sensowne wartości dla HOMEHOST, MAILADDR.
I teraz możemy odbudować obraz initrd:
update-initramfs -u
Optymalizacja macierzy RAID5
Sam proces tworzenia macierzy może zająć kilka/kilkanaście godzin - dlatego warto mu pomóc kilkoma zmianami.
speed_limit_xxx
Na pierwszy rzut - domyślne wartości dla minimalnej i maksymalnej prędkości budowania/regenerowania/odtwarzania macierzy RAID5, można je sprawdzić:
cat /proc/sys/dev/raid/speed_limit_max
200000
cat /proc/sys/dev/raid/speed_limit_min
1000
Domyślnie jest to minimum 1MB/s i maksimum 200MB/s. Podbijając minimalną prędkość do 10~50MB/s można kosztem większego obciążenia systemu zmusić macierz by odbudowywała się szybciej. Osobiście uważam tą optymalizację za mało znaczącą bo cały mechanizm dość elastycznie reaguje na obciążenie systemu i jeśli nic nie robimy to prędkości odbudowy są dość wysokie. Ale można to zrobić tak:
echo 50000 > /proc/sys/dev/raid/speed_limit_min
lub tak:
sysctl -w dev.raid.speed_limit_min=50000
stripe_cache_size
Ta optymalizacja pomogła mi dużo - ok. 30% wzrost wydajności macierzy (również w czasie odbudowy parzystości). Możemy sprawdzić wartość tego parametru, np. tak:
cat /sys/block/md0/md/stripe_cache_size
Domyślnie jest to wartość 128 - bida z nędzą, u mnie ustawienie na 32768 (maksymalna wartość tego parametru) dało największy wzrost wydajności - ale już 8192 znacznie poprawiło wydajność.
for i in 256 512 1024 2048 4096 8192 16384 32768;
do
echo "Testowanie $i"
echo $i > /sys/block/md0/md/stripe_cache_size
sync
echo 3 > /proc/sys/vm/drop_caches
dd if=/dev/zero of=file bs=1M count=10000
done
Wyłączenie NCQ dla wszystkich dysków w macierzy
Wydało mi się to nieco kontrowersyjne bo NCQ powinno pomagać przy losowych odczytach/zapisach - ale zapuściłem test bonnie++ i okazało się że z włączonym NCQ czasy dostępu dla niektórych obciążeń rosną nawet dziesięciokrotnie! Warto więc sprawdzić tą opcję pod przewidywanym przez nas scenariuszem obciążenia.
NCQ dla poszczególnych dysków można wyłączyć np. tak:
for d in sdb sdc sdd
do echo 1 > /sys/block/$d/device/queue_depth
done
Wyłączenie cache dyskowych
Wyłączenie wbudowanej w dyski pamięci cache akurat nie zwiększa wydajności ale w przypadku awarii zasilania (lub innej gwałtownej awarii systemu) zwiększa szanse macierzy na przeżycie takiego incydentu. Obecnie większość systemów plików korzysta z opóźnienia zapisu by bardziej optymalnie zapisać dane na dysku - dlatego gdy zapisujemy dany to najpierw trafiają one do cache systemowego. Dopiero po sync’u są przesyłane do cache dyskowego skąd dopiero po pewnym czasie trafiają na dysk. Wyłączenie pamięci cache na dyskach “usuwa” nam to drugie opóźnienie.
hdparm -W0 /dev/sd*
Zmiana parametrów odczytu z wyprzedzeniem
Bardzo ważnym parametrem mającym wpływ na wydajność macierzy jest odpowiednie ustawienie odczytu z wyprzedzeniem. Obecnie ustawioną wartość możemy sprawdzić tak (wartość wyrażona jest w 512 bajtowych sektorach):
blockdev --getra /dev/md0
U mnie domyślnie było 4096 (a na innym starszym systemie tylko 1536) to może być zbyt mało dla konfiguracji RAID. Większe wartości można ustawić np. tak:
blockdev --setra 65536 /dev/md0
A tak można wykonać sprawdzanie, która wartość będzie dla nas najbardziej optymalna:
dd if=/dev/zero of=file bs=1M count=10000
for i in 1536 4096 8192 16384 32768 65536 131072 262144 524288;
do
echo "Testowanie $i"
blockdev --setra $i /dev/md0
sync
echo 3 > /proc/sys/vm/drop_caches
dd if=file of=/dev/null bs=1M
done
Tworzenie zasobu LVM
Mając już macierze tworzę na niej volumen LVM - najpierw przygotowanie zasobu:
pvcreate /dev/md0
Jeżeli w /etc/lvm/lvm.conf mamy ustawione opcje:
md_component_detection = 1
md_chunk_alignment = 1
data_alignment_detection = 1
To LVM powinien automatycznie wykryć rozmiar chunk’a z RAID’a i dostosować swoje metadane, oraz początek danych tak by wszystko było prawidłowo wyrównane względem macierzy.
Jeśli nie mamy szczęścia (bardzo stare jajko/LVM) to będziemy musieli użyć opcji -metadatasize i/lub -dataalignment:
pvcreate --metadatasize 500k /dev/md0
Teraz ciekawostka - LVM potrzebuje na 192KB na dane nagłówkowe każdego wolumenu i każdy utworzony później zasób byłby o te 192KB przesunięty, więc … trafia nasze wyrównanie do 128KB. Dlatego zmuszamy LVM’a by zaalokował nieco więcej - tutaj 256KB. OK - ale w poleceniu jest 250 - WTF? I to aby było zabawnie jest to jak najbardziej prawidłowa wartość - nie wiem jaka w tym logika, ale by metadane zajmowały 256KB podajemy 250k, by zajmowały 512KB podajemy 500k itd…
Inaczej jest z opcją -dataalignment, tutaj najbardziej optymalnie należy podać rozmiar chunk’a*ilość aktywnych dysków (dla RAID5 odejmujemy jeden) - albo minimalnie rozmiar chunka, np.:
pvcreate --dataalignment 512K /dev/md0
Poprawność możemy sprawdzić poleceniem:
pvs /dev/md0 -o+pe_start
PV VG Fmt Attr PSize PFree 1st PE
/dev/md0 vgraid lvm2 a- 1,82t 488,89g 512,00k
U mnie 1st PE zaczyna się na 512KB, więc jest OK.
Teraz tworzymy grupę:
vgcreate vgraid /dev/md0
Polecenie vgcreate posiada parametr -s który pozwala określić do wielokrotności jakiej wartości będzie zaokrąglana wielkość wolumenu - wartość ta powinna być wielokrotnością chunk’a z macierzy. Domyślnie ma ona wartość 4MB więc wszystko będzie ładnie wyrównane.
I możemy zacząć tworzyć volumeny logiczne:
lvcreate -L1T -nsrv vgraid
Formatowanie
To teraz formatowanie - tutaj też czasem trzeba się wysilić by utworzony przez nas filesystem działał możliwie optymalnie na macierzy i bloku o odpowiednim rozmiarze. W przypadku filesystemu na macierzy są dwa ważne parametry: stride i stripe-width. Stride powinien odpowiadać rozmiarowi podanemu jako chunk podczas tworzenia macierzy ale wyrażonego w blokach systemu plików (domyślnie 4KB). Stripe-width powinno być ustawione na: stride * N, gdzie N to ilość aktywnych dysków w macierzy (dla RAID5 jest to ilość dysków minus 1) - przykładowo dla bloku 4KB i chunk’a 512KB, stride powinien wynosić 128 (512/4). Z kolei stripe-width dla 3 dysków to 128*(3-1)=256. Prawidłowe dobranie tych parametrów może dać wzrost wydajności rzędu 40% (według moich testów). Teoretycznie na nowszych systemach tworzone systemy plików automatycznie powinny wykryć najbardziej optymalne wyrównanie - możemy więc spróbować puścić format bez tych parametrów i później skontrolować ich wartości poleceniem:
tune2fs -l /dev/vgraid/srv
Na początek przykład dla systemu plików dla małych i średnich plików:
mkfs.ext4 -E stride=128,stripe-width=256,resize=4T -m0 /dev/vgraid/srv
Jeden dodatkowy parametr to resize - pozwala on zmienić domyślne ustawienie maksymalnego rozmiaru do którego możemy powiększyć dany filesystem - domyślnie jest to wartość 1000 razy większa od początkowej wielkości - ciut przekozaczone. Może nie oszczędzi to dużo miejsca na dysku (kilkadziesiąt/kilkaset MB) ale na pewno skróci czas fsck’a.
Kolejny dodatek to -m0 które wyłącza alokację 5% przestrzeni dyskowej dla root’a i usług systemowych - po prostu tutaj tego nie potrzebuję a 5% z 1TB to 50GB marnującego się miejsca!
Jeśli wiemy że będziemy przechowywać na danym zasobie tylko stosunkowo duże pliki to można użyć takich opcji:
mkfs.ext4 -E stride=128,stripe-width=256,resize=4T -T largefile -m0 /dev/vgraid/srv
Opcja -T to wykorzystanie szablonów opcji dla tworzenia systemów plików, które można edytować i dodawać w pliku: /etc/mke2fs.conf. Szablon largefile wykorzystuje mniejszą liczbę inodów dla nowego filesystemu, jeśli zamierzamy przechowywać głównie duże pliki to zmniejszy to czas formatowania i późniejszych fsck’ów na tym systemie plików.
Testowanie wydajności
Zalecałbym testowanie wydajności na kolejnych etapach przygotowania dysków i powtarzać te same benchmarki po każdej zmianie, tak więc testujemy:
- Na początek wszystkie dyski, z których zamierzamy zbudować RAID’a by wykluczyć ewentualne “padaki”/uszkodzone kable, itp. Np. hdparm/dd na czystym dysku i dodatkowo iozone/bonnie++ na filesystemie by sprawdzić czy nie skopaliśmy wyrównania partycji.
- Po zbudowaniu RAID’a powtarzamy testy - na całym urządzeniu (dd) i po sformatowaniu (iozone/bonnie++) by upewnić się że RAID jest prawidłowo wyrównany (przy czym przy RAID5 możemy się spodziewać wyników przy zapisie niższych niż przy odczycie - jest to OK). Jest to też dobry moment na sprawdzenie kilku optymalizacji dla macierzy: stripe_cache_size, wyłączenie NCQ, ustawienia odczytu z wyprzedzeniem, wyłączenie cache dysków - po każdej z tych zmian ponawiamy benchmarki by upewnić się że uzyskaliśmy poprawę/lub nie.
- Po przygotowaniu LVM’a - ponawiamy benchmarki na volumenie by upewnić się że nie skopaliśmy wyrównania partycji/chunk’a/itd…
- Dopieszczamy opcje formatowania filesystemu i jego montowania (np. noatime, commit, data, itd) - i znów posiłkujemy się benchmarkami by potwierdzić że pniemy się z wydajnością w górę.
Jeśli myślicie że to dużo to zalecałbym powtórzenie części benchmarków 23 krotnie by upewnić się że wyniki nie odbiegają znacznie od siebie. Dodatkowo powinniśmy czyścić przed każdym banchmarkiem cache dyskowy aby mieć pewność że lepsze wyniki nie są skutkiem wczytania danych do pamięci. Z tego samego powodu jeśli uruchamiamy benchmarki to ilość zapisywanych/odczytywanych danych powinna być minimum 1,52 razy większa niż pamieć RAM zainstalowana w systemie by na pewnie wszystkie dane nie zmieściły się w cache’u. Oczywiście można to zlać ale później nie ma się co dziwić że system działa wolno - a na produkcyjnej maszynie dużo trudniej zaorać całą konfiguracją i utworzyć od początku z prawidłowym wyrównaniem.
Zalecane jest wykorzystanie IOZone lub Bonnie++ ponieważ testują one nie tylko prosty sekwencyjny odczyt, ale również tworzenie/kasowanie plików o różnych rozmiarach i w różnej ilości - to pozwala lepiej sprawdzić opóźnienia występujące przy przewidywanych przez nas obciążeniach oraz upewnić się że cała zabawa z wyrównywaniem zasobów miała sens. Oczywiście to tylko zalecenia 😉
hdparm
W przypadku macierzy wykorzystanie prostego hdparm’a do testów:
hdparm -tT /dev/md0
nie zwróci realnych i sensownych wyników. Pomiar jest zbyt krótki by uzyskać sensowne wyniki - lepiej wykorzystać dd z dużą ilością danych do odczytu.
dd
Narzędzie jakże prymitywne a tak przydatne. Możemy nim zmierzyć sekwencyjny odczyt/zapis z/do macierzy i uzyskać bardziej realne wyniki niż hdparm’em. Wystarczy wymusić operację na ok. dwukrotnie większej ilości danych niż ilość pamięci RAM. Dodatkowo czyścimy cache’e przed i po mierząc całościowy czas, np. tak:
sync; echo 3 > /proc/sys/vm/drop_caches; time (dd if=/dev/zero of=/mnt/test/test.img bs=1024K count=10240 && sync)
Jest to szczególnie przydatne np. przy dopasowywaniu optymalnej dla nas wartości parametru stripe_cache_size, wystarczy przygotować odpowiednią pętlę:
for i in 128 256 512 1024 2048 4096 8192 16384 32768;
do
echo "stripe_cache_size $i"
echo $i > /sys/block/md0/md/stripe_cache_size
sync; echo 3 > /proc/sys/vm/drop_caches; time (dd if=/dev/zero of=/mnt/test/test.img bs=1024K count=10240 && sync)
done
Parametr bs określa bufor wykorzystywany przy operacjach odczytu/zapisu - można go dostosować do rozmiaru chunk’a/stripe-width/itp.. count określa jak dużo takich buforów odczytać/zapisać - w powyższym przypadku jest to 10 tys. jednomegabajtowych buforów więc łącznie 10GB.
bonnie++
Bonnie++ wymaga nieco przygotowania ale wyniki w moim przypadku bardzo odpowiadały rzeczywistym. Co pokrótce trzeba zrobić:
mkdir /srv/test
chown -R guest:guest /srv/test
bonnie++ -d /srv/test -s 16g -m nazwa_maszyny -f -u guest
Możemy dodać opcję -b by po każdej operacji wykonywany był sync - to byłoby coś podobnego do systemów bazodanowych lub pocztowych. Jeżeli chcemy zasymulować standardowe operacje na plikach to nie potrzebujemy tej opcji.
iozone
W najprostszym wykonaniu:
iozone -a
Wykona to serię pomiarów na różnych rozmiarach plików, ilości powtórzeń itd. Najbardziej interesująca opcją w konfiguracji RAID jest “Stride read”.
iozone -S 8192 -t 1
Parametr -S przekazuje rozmiar pamięci cache procesora - wykorzystywany do alokacji pamięci blokami itp (sprawdzałem czy to cokolwiek pomoże.. ale nie widziałem dużej różnicy).
Parametr -t 1 to benchmark przepustowości dysku a parametr cyfrowy określa liczbę równoczesnych wątków, które będą odczytywać/zapisywać - można w ten sposób zasymulować np. równoczesny streaming dla wielu źródeł, itp.
iozone -S 8192 -a -s 40960
Tutaj parametr -s wskazuje na jakim rozmiarze pliku w KB ma być prowadzony benchmark - tutaj 40MB.
Podsumowanie
Ogólnie zadowolony jestem że udało mi się to wszystko zebrać w jednym poście bo dotychczas miałem to zapisane w wielu różnych zakładkach i spory problem gdy potrzebowałem “właśnie tego jednego polecenia”. Ale niezadowolony jestem z tego że nie udało mi się ustalić całości tego postępowania dla dysków o sektorach/erase block’ach większych niż 4 KB. Chodzi mi szczególnie o brak jasnego wyjaśnienia czy RAID5 jest prawidłowo wyrównywany bo według jednych tak właśnie jest, a według innych tak nie jest. Stąd niektórzy zalecają by stosować format metadanych dla macierzy w wersji 0.9 lub 1.0 zamiast 1.2 ale nie ma jasnych źródeł tego rozumowania. Mam nadzieję że kiedyś uda mi się to jednoznacznie rozsądzić - na pewno zaktualizuję wtedy tego posta.
Źródełka na których oparłem to HOWTO
http://serverfault.com/questions/390294/mdadm-raid5-too-slow-when-writing
http://serverfault.com/questions/250707/why-does-mdadm-write-unusably-slow-when-mounted-synchronously
http://serverfault.com/questions/416321/mdadm-raid-5-failed-with-2-drives-while-rebuilding
http://www.cyberciti.biz/tips/linux-raid-increase-resync-rebuild-speed.html
http://askubuntu.com/questions/20852/making-stripe-cache-size-permanent
http://h3x.no/2011/07/09/tuning-ubuntu-mdadm-raid56
https://raid.wiki.kernel.org/index.php/Performance
http://www.mjmwired.net/kernel/Documentation/md.txt
http://wiki.hetzner.de/index.php/Partition_Alignment/en
http://www.fhgfs.com/wiki/wikka.php?wakka=PartitionAlignment
O tym że LVM na RAID5 sam się wyrównuje:
http://marc.info/?l=linux-raid&m=126267824425009&w=2
http://www.redhat.com/archives/linux-lvm/2009-September/msg00092.html
MDADM metadata format 1.2 wyrownuje sie do 4KiB:
http://www.redhat.com/archives/linux-lvm/2009-September/msg00092.html
Kalkulator stride’a
http://busybox.net/~aldot/mkfs_stride.html
Format raid’a:
https://raid.wiki.kernel.org/index.php/RAID_superblock_formats
Wyrównanie do 4kb - choć wydaje mi się że gościu robi to na czuja i ledwie mu się udało:
http://blog.bigsmoke.us/2010/05/13/aligning-partitions-with-raid-and-lvm-on-drives-with-4-kb-sectors