Z racji tego, że wczoraj światło dzienne ujrzało wydanie 2.0.0 systemu DragonFlyBSD, zainteresowałem się systemem plików o wszystko mówiącej nazwie Hammer. Nie jest on jeszcze domyślnym systemem plików w DraongFly’aju, gdyż jako nowość wymaga lepszego przetestowania. Posiada on kilka funkcjonalności które po raz pierwszy pojawiły się w zfsie w dziesiątym wydaniu Solarisa, np. snapshoty czy odtwarzanie systemu plików bez scandiska, ale w wielu miejscach został on zaprojektowany zupełnie inaczej. Jednak ocena konkretnych funkcjonalności zależy od potrzeb danego użytkownika, to wydajność systemu plików już interesuje wszystkich jednakowo. To też przy porównaniu fsów skupiłem się tylko na wydajności i obciążeniu procesorów.

Do rywalizacji wybrałem:

  1. ufs 2 na systemie FreeBSD 7.0 amd64
  2. zfs na systemie FreeBSD 7.0 amd64
  3. ufs na systemie DragonFly 2.0.0 i386
  4. hammer na systemie DragonFly 2.0.0 i386

Użyłem systemu DragonFly w wersji 32-bitowej ponieważ wersja 64-bitowa jest jeszcze nie dostępna, a ze względu na błąd w obsłudze SMP, działał on tylko na jednym rdzeniu w porównaniu do FreeBSD który wykrył obydwa rdzenie procesora. Całość testów dla mojej wygody odbyła się pod VMWare server 2.0 rc1, co znacznie obniżyło wyniki, ale nadal pozwoliło na dokonanie pewnych porównań.

Tabelka z wynikami
Sequential Output Sequential Input Random
Per Char Block Rewrite Per Char Block Seek
K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU
FreeBSD ufs2 (1st try) 1013 2.8 27469 57.8 33191 95.5 31639 99.1 74992 99.1 3221.8 169.9
FreeBSD ufs2 (2nd try) 34867 90.2 35059 81 29666 94.4 30936 99.1 71827 99.1 2848.6 168.4
FreeBSD zfs (1st try) 1245 4.6 12032 13 545 0.2 162637 39.4 126149 5 709 1.8
FreeBSD zfs (2nd try) 13473 48.5 8487 41.8 3749 2 22577 58.1 299993 24.1 603.6 3.5
DragonFly ufs (1st try) 2116 4.9 29181 8.6 4650 3.8 29968 91.8 368998 67.5 18424.7 60.9
DragonFly ufs (2nd try) 27852 63.7 46395 13.4 18635 13.3 30210 92.9 358283 43.3 17930.5 63.1
DragonFly hammer (1st try) 24239 61.6 52242 12.7 25851 10 35345 98.4 432856 75.9 6378.8 27
DragonFly hammer (2nd try) 25128 59.9 55175 12.6 34056 17.1 33006 93.2 432851 64.1 6888.6 30

Jak widać w załączonej tabelce pierwsza próba pomiarów na platformie FreeBSD była dużo wolniejsza od drugiej, jednak zużywała dużo mnie zasobów procesora. Jeśli chodzi o DragonFly’aja to tutaj podobny efekt widać tylko przy ufsie. Bierze się to stąd, że przy ponownym wykonaniu tych samych czynności jedna po drugiej można uzyskać duże przyspieszenie dzięki systemowi cache. Natomiast wyniki uzyskane przez hammera wywołują na mnie wrażenie, że już pierwszy zapis i odczyt wykonywany jest w cache’u, a dopiero w wolnym czasie jest on synchronizowany z dyskiem. System hammer uzyskał najlepsze przepustowości jeśli chodzi o zapis danych w blokach po 64 KB jak, przy nadpisywaniu danych jak i przy odczycie blokowym, w czołówce był także jeśli chodzi o zapis w trybie znakowym. Natomiast zfs wyprzedził konkurencje ok. pięciokrotnie jeśli w pierwszej próbie zapisu w trybie znakowym, jednak przy drugiej próbie uzyskał wynik najsłabszy. Zfs jeszcze tylko przy odczycie blokowym nawiązał walkę z konkurencją, bo w pozostałych wynikach był już zdecydowanie słabszy, choć jednocześnie zużywał najmniej mocy procesorów. Jeżeli chodzi o porównanie ufsa i ufsa 2, to wersja pierwsza nieco szybciej zapisywała dane, natomiast wersja druga jednak już dużo szybciej je nadpisywała. W porównaniu odczytu znakowego minimalne zwycięstwo wersji drugiej, jednak przy odczycie blokowym czterokrotna przewaga ufsa 1, sprawdził on się także sześciokrotnie szybciej przy wyszukiwaniu danych i potrzebował do tego trzykrotnie mniej mocy procesora. Wynika to z tego iż ufs 2 mimo, że jest nowszą wersją, to posiada ona znacznie więcej funkcjonalności do których obsługi potrzeba czasu procesora..
Archiwalny news dodany przez użytkownika: Magik.
Kliknij tutaj by zobaczyć archiwalne komentarze.

Oznaczone jako → 
Share →