SantyagoSantyago
YouTube RSS Google+ Facebook GitHub

Kategorie wpisów

QRCode

QR Code

Reklama na Blogu

Najnowsze poradniki

Ostatnie komentarze

Popularne wpisy

Facebook

Google+

Ostatnie fotografie

polskie-gorypolskie-gorypolskie-gorypolskie-gorypolskie-gorypolskie-gorypolskie-gorypolskie-gorypolskie-gorywieliczka-szyb-danilowicza

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:

  1. 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:

  1. blockdev --getsz /dev/sda1
  2. 125788887

Jako rozmiar bloków przyjęliśmy na początku 256 KiB, a więc 512 sektorów.

  1. 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:

  1. mount /dev/mapper/ssdcache /mnt/sda1

Testy: Kopiowanie pliku (2,5 GiB)

  1. echo 3 > /proc/sys/vm/drop_caches
  2. 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

  1. echo 3 > /proc/sys/vm/drop_caches
  2. 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)

  1. echo 3 > /proc/sys/vm/drop_caches
  2. time cp -R /usr/src/linux-3.9/ /dev/shm/

real    0m48.583s
user    0m0.243s
sys     0m2.513s

  1. echo 3 > /proc/sys/vm/drop_caches
  2. 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

  1. cd /usr/src/linux-3.9
  2. echo 3 > /proc/sys/vm/drop_caches
  3. time make -j4

real    6m3.854s
user    19m51.270s
sys     1m29.049s

  1. cd /mnt/sda1/linux-3.9
  2. echo 3 > /proc/sys/vm/drop_caches
  3. 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 Komentarze
Avatar 1
Mr Q Linux x86_64 / Mozilla Firefox 20.0
05 maj 2013 - 13:02 Warszawa

Pytani brzmi: Jak się takie rozwiązanie zachowuje gdy oryginalne pliki znajdują się na szyfrowanej partycji? W cache siedzi wersja zaszyfrowana czy jawna?

Avatar 2
Korneliusz Linux x86_64 / Mozilla Firefox 19.0
05 maj 2013 - 18:50 Bytom

Szczerze powiem, że nie wiem, ale chyba wzięli to pod uwagę.

Avatar 1
Sebastian Linux x86_64 / Mozilla Firefox 20.0
05 maj 2013 - 16:45 Warszawa

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).

Avatar 1
rozie Linux x86_64 / Mozilla Firefox 20.0
05 maj 2013 - 17:35 Poznań

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.

Avatar 2
Korneliusz Linux x86_64 / Mozilla Firefox 19.0
05 maj 2013 - 18:51 Bytom

Być może - wolnej chwili sprawdzę jak sprawuje się cały system z tym rozwiązaniem

Avatar 2
PKSobon Linux x86_64 / Safari 537.31
06 maj 2013 - 22:25 Radom

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.

Avatar 1
mari Windows 7 / Mozilla Firefox 21.0
25 sierpień 2013 - 21:13 Brak informacji

sektory 512bajtów?w obecnych dyskach?
po co męczyć je emulacją trupa?
wszystkie scalaki mają standardowo 4kB jak i wszystkie nowe dyski

Avatar 2
Korneliusz Linux x86_64 / Mozilla Firefox 21.0
25 sierpień 2013 - 22:26 Bytom

Mówisz, że 4kB bloki dadzą poprawę?

Avatar 1
znik Windows 7 / Mozilla Firefox 25.0
13 listopad 2013 - 09:13 Lublin

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.

Avatar 2
Korneliusz Linux Ubuntu / Mozilla Firefox 25.0
13 listopad 2013 - 11:25 Katowice

Bardzo cenna informacja - dziękuję. Wygląda na to, że będę musiał sie przyjrzeć sprawie raz jeszcze.

Skomentuj wpis