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:
- ufs 2 na systemie FreeBSD 7.0 amd64
- zfs na systemie FreeBSD 7.0 amd64
- ufs na systemie DragonFly 2.0.0 i386
- 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ń.
| 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.