SantyagoSantyago
YouTube RSS Facebook GitHub

Mam dziś malutki prezent dla zarejestrowanych użytkowników /dev/Jarzębski. Są to mianowicie klucze Steam do gier Brutal Legend (1 klucz) oraz Trine 2: Complete Story (1 klucz). Oba tytuły dostępne są również dla Linuksa. Aby otrzymać wybrany przez siebie klucz, należy posiadać konto na Blogu oraz mieć na stanie przynajmniej jeden komentarz przed publikacją tego wpisu. Jeśli jest osoba chętna, proszę o pozostawienie komentarza pod tym wpisem.

Przy okazji zaprszam do aktywności, gdyż planuję więcej, mniejszych lub większych giftów :)

Reklama

Nastąpił bardzo ciekawy obrót sytuacji w "obozie" Intela, bowiem do nadchodzącej wersji 3.0 sterowników x86-video-intel pojawił się commit dodający obsługę XMir, jednak został on po kilku dniach cofnięty przez Chrisa Wilsona.

Pomimo tego, że łatka pozwalająca na uruchomienie sterowników DDX X.Org pod kontrolą XMir (warstwa serwera Mir od Canonical) była analogiczna do XWayland dla serwera Wayland oraz skomentowana przez Canonical jakoby posiadała już stabilne API, to z jakiegoś powodu nie została ona zaakceptowana.

Najciekawszy okazuje się jednak sam komentarz Chrisa Wilsona, w którym wyjaśnia on powód cofnięcia łatki:

"We do not condone or support Canonical in the course of action they have chosen, and will not carry XMir patches upstream. -The Management"

"Nie akceptujemy i nie wspieramy firmy Canonical w drodze jaką obrała i nie dostarczymy łatek dla XMir w głównej gałęzi."

Wszystko wskazuje więc na to, że Cannonical będzie musiał dostarczać swoje łatki do Mir/XMir poza oficjalną gałęzią sterowników Intela.

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.