Android
Arduino
Blog
Dystrybucje
Filmy
Hardware
KDE 4
KDE 5
Propaganda
Przepisy
Raspberry Pi
Rozrywka
Software
Varia
PRZEWAGA NAD RASPI I NAD ARMAMI..
kezook
BB
True
ori
faucolt
Darek
tomek
kezook
Wbm
Jedną z nowości zawartych w jądrze 3.9.0 jest zdolność wykorzystywania dysków SSD przez device mappera jako cache dla wolniejszych dysków talerzowych. Idea działania polega na przechowywaniu na mniejszym, ale szybszym dysku SSD kopii plików, do których odwołujemy się najczęściej .
Na niemal identycznej zasadzie działają hybrydowe dyski twarde - np. Seagate Momentus XT. Istotną różnicą jest jednak to, że powyższe rozwiązanie wykorzystuje dwa napędy zamiast jednego.
Konfiguracja testowa
Do testów posłuży nam konwencjolany dysk twardy Western Digital Caviar Black oraz Samsung SSD 830. Platformę testową stanowi Intel i5-2500 wraz z 16GB pamięci RAM.
Przygotowanie dysku SSD
Jedna z cech tego mechanizmu cache z wykorzystaniem dysku SSD jest rozdzielenie jego powierzchni pomiędzy obszarem przechowywania metadanych, a obszarem cache, który będzie gromadził nasze najczęściej wykorzystywane dane. Naturalnie rozmiar cache powinien być jak największy i nie ma większego kłopotu z wyborem jego rozmiaru. Kłopotliwy może być jednak obszar metadanych, którego rozmiar powinniśmy wyliczyć z poniższego wzoru:
4 MiB + (16 B * liczba_bloków)
Rozmiar partycji przyjmiemy 55 GiB, a jako rozmiar bloków 256 KiB - czyli 512 sektorów po 512 B. A więc:
Liczba bloków = 55 GiB / 256 KiB = 225280 bloków
Metadane = 4 MiB + (16 B * 225280) = 7798784 B = 7616 KiB
Przeliczmy jeszcze nasze wartości na 512 B sektory:
Partycja Cache = 55 GiB / 512 = 115343360 sektorów
Partycja Metadanych = 7616 KiB / 512 = 15232 sektory
Za pomocą programu fdisk przygotujemy teraz dysk SSD na podstawie powyższych wartości:
- fdisk -u=sectors -S32 -H32 /dev/sdb
Konfiguracja devmappera
Kiedy mamy już przygotowany dysk SSD, musimy skonfigurować nasz cache. Dla testów ograniczyłem się jednynie do partycji /dev/sda1, do której to będziemy potrzebowli rozmiar w sektorach:
- blockdev --getsz /dev/sda1
- 125788887
Jako rozmiar bloków przyjęliśmy na początku 256 KiB, a więc 512 sektorów.
- dmsetup create ssdcache --table '0 125788887 cache /dev/sdb1 /dev/sdb2 /dev/sda1 512 1 writeback default 0'
Pozostaje nam już tylko zamontować naszą "hybrydę" poniższym poleceniem:
- mount /dev/mapper/ssdcache /mnt/sda1
Testy: Kopiowanie pliku (2,5 GiB)
- echo 3 > /proc/sys/vm/drop_caches
- dd if=/storage/dystrybucje/Slackware/slackware-14.0-install-dvd.iso of=/dev/null
4802704+0 przeczytanych recordów
4802704+0 zapisanych recordów
skopiowane 2458984448 bajtów (2,5 GB), 25,2681 s, 97,3 MB/s
- echo 3 > /proc/sys/vm/drop_caches
- dd if=/mnt/sda1/slackware-14.0-install-dvd.iso of=/dev/null
4802704+0 przeczytanych recordów
4802704+0 zapisanych recordów
skopiowane 2458984448 bajtów (2,5 GB), 20,3597 s, 121 MB/s
Testy: Kopiowanie źródeł jądra 3.9.0 (1,2 GiB)
- echo 3 > /proc/sys/vm/drop_caches
- time cp -R /usr/src/linux-3.9/ /dev/shm/
real 0m48.583s
user 0m0.243s
sys 0m2.513s
- echo 3 > /proc/sys/vm/drop_caches
- time cp -R /mnt/sda1/linux-3.9/ /dev/shm/
real 0m38.133s
user 0m0.253s
sys 0m2.344s
Testy: Kompilacja jądra 3.9.0
- cd /usr/src/linux-3.9
- echo 3 > /proc/sys/vm/drop_caches
- time make -j4
real 6m3.854s
user 19m51.270s
sys 1m29.049s
- cd /mnt/sda1/linux-3.9
- echo 3 > /proc/sys/vm/drop_caches
- time make -j4
real 6m8.074s
user 19m56.077s
sys 1m29.865s
Podsumowanie
Zauważalnych różnic praktycznie nie ma. Jest odrobinę szybciej, jednak należy zastanowić się, czy nie lepszym rozwiązaniem jest postawienie systemu na dysku SSD zamiast stosować cache. Dotyczy się to również testów uruchomieniowych, gdzie programy uruchamiały się praktycznie w tym samym czasie. Przyjrzyjmy się jeszcze na koniec statystykom:
ssdcache: 0 125788887 cache 676/4544 4595 448904 8957 209538 0 607 627 579 0 2 migration_threshold 204800 4 random_threshold 4 sequential_threshold 512
Podczas krótkiej pracy z tym rozwiązaniem można zauważyć, że procent trafień podczas odczytu to zaledwie 1% (4595 trafień i 448904 chybień). Zapis wyszedł trochę lepiej bo, aż porywające 4% (8957 trafień i 209538 chybień).
Czy warto? Moim zdaniem nie - jednak na to pytanie musicie sobie odpowiedzieć sami.
Komentarze
Pytani brzmi: Jak się takie rozwiązanie zachowuje gdy oryginalne pliki znajdują się na szyfrowanej partycji? W cache siedzi wersja zaszyfrowana czy jawna?
Szczerze powiem, że nie wiem, ale chyba wzięli to pod uwagę.
Nie skreślałbym jeszcze tego rozwiązania, dobre rezultaty dadzą dobrze dobrani planiści, którzy odpowiednio będą zarządzać wymianą danych w cache - w końcu pomiędzy SSD a HDD nie ma takich różnic jak np. między cache L3 w procesorze i RAM (zarówno co do prędkości jak i zasady działania).
No różnica między SSD a HDD jest około dziesięciokrotna. Rozwiązanie może być fajne już teraz, ale nie będzie to widoczne w takim syntetycznym i jednokrotnym teście.
Być może - wolnej chwili sprawdzę jak sprawuje się cały system z tym rozwiązaniem
Kupiłem sobie dysk SSD, jeden z tańszych na rynku, ale nie znowu jakiś tam najgorszy, poszperałem i wybrałem optymalny pod względem cena/jakość. Postawiłem na nim system i uważam, że jest to olbrzymi krok w przód w stosunku do HDD.
Jeśli zmiany rzeczywiście są tak mało odczuwalne jak to zaznaczasz, to nie ma sensu się bawić. Iść całkowicie w system na SSD, katalog /home na SSD, a reszta danych trzymana na tradycyjnych HDD.
sektory 512bajtów?w obecnych dyskach?
po co męczyć je emulacją trupa?
wszystkie scalaki mają standardowo 4kB jak i wszystkie nowe dyski
Mówisz, że 4kB bloki dadzą poprawę?
Taki test niczego nie dowodzi. Jedynie tyle, że taki cache uznał że dane są słabo używane, więc nie ma sensu ich pchać na SSD. Dopóki ssd cache nie \'nauczy\' się co jest najczęściej używane, to nie będzie realicował cache. System trzeba trochę pomielić :)
btw. czy w systemie plikowym są jakiekolwiek informacje detaliczne dla plików jak często są używane? byłyby one pomocne. Jeśli nie, cache musi się tego nauczyć na bieżąco.
ważne jest też aby rozpocząć blok partycji od właściwego sektora, aby nie ciąć na kawałki 4kb bloków fizycznych przy emulacji 512k, bo to degraduje wydajność. Warto też wielkość bloku określić na 4kB, aby trimming się nie mordował z ułamkami. Inaczej nawet system natywnie postawiony na SSD za moment zwolni i tyle będzie radości z wydajności.
Bardzo cenna informacja - dziękuję. Wygląda na to, że będę musiał sie przyjrzeć sprawie raz jeszcze.
