Wydajnościowy test systemów plików

Wiedząc, że będzie mowa o systemach plików, zapewne wielu czytających ten test wie o istnieniu tylko dwóch – NTFS i FAT. Dzieje się tak, gdyż te dwa systemy plików są wspierane przez systemy operacyjne Microsoftu, a przecież wiele osób pracuje właśnie tylko na systemach z rodziny Windows. Pozostaje również mniejsza część osób, które wiedzą o istnieniu linuksowych systemów plików takich jak ext2, 3 i 4 oraz tych trochę mniej spotykanych jak btrfs, xfs czy razerfs. O ich najważniejszych cechach, możemy przeczytać na przykład w najpopularniejszej, internetowej encyklopedii jaką jest Wikipedia. Niestety rzadko porusza się problem różnic między nimi jeżeli chodzi zwykłego użytkownika, który nie będzie magazynował na swoim dysku plików o wielkości 16 Terabajtów, na partycji o rozmiarze 16 Eksabajtów (1 Eksabajt = 1024*1024 Terabajtów). Zwykłemu użytkownikowi komputera chodzi głównie o to, jak szybko jego dane zostaną zapisane i odczytane z dysku.

W teście chciałem przedstawić różnice w wydajności zapisu oraz odczytu plików, podczas użycia poszczególnych systemów plików. Poniżej znajdziecie odpowiedzi na takie pytania jak: Czy systemy plików typowo Microsoft'owskie są wydajniejsze od tych Linuksowych? Czy pracując na systemie Linux jest sens wybierać bardziej „egzotyczne” systemy plików jak btrfs lub jfs, czy lepiej pozostać na starym dobrym ext3 lub 4. A może jednak postawić na współpracujący z Windowsami system plików NTFS? Serdecznie zapraszam do czytania!

Spis treści

• Wstęp
• Platforma testowa
• Kilka słów o platformie testowej
• Metodologia
• Wykorzystane systemy plików
• Testy
• Podsumowanie

Platforma testowa:

Procesor: Intel Pentium 4 3,2 GHz HT

Płyta główna: Gigabyte GA-8SGXL @ 8S648fx

Pamięć: 256 MB + 512 MB DDR 333 MHz

Karta graficzna: GeForce 2 MX 400 64 MB

Dysk twardy: WD WD800JB 80 GB

Zasilacz: Amacrox Warrior AX400-PNF

System operacyjny: Linux Ubuntu 9.10 LTS

Kilka słów o platformie testowej

Zapewne osoby, które czytają moje miniRecenzje na bieżąco zauważyły, że zmieniła się platforma testowa. Niestety nie mogłem przeprowadzić testów na mojej wydajniejszej platformie testowej. Mając do wyboru robić test na mniej wydajnej platformie lub go w cale nie robić, postanowiłem jednak go przeprowadzić. Wiadomo, nie jest ona jakimś demonem szybkości, ba nie nadaje się do grania nawet w starsze tytuły sprzed sześciu czy nawet siedmiu lat, ale dlaczego by nie popracować z Linuksem.

Jeżeli zaś chodzi o Linuksa... Wybrałem wersję będącą już ponad od roku dostępną, ale za to w pełni pozbawioną błędów. Zapewne tutaj część osób się zastanawia – przecież są dostępne wersje 10.04 LTS oraz 10.10, które są wersjami finalnymi i nie powinny mieć błędów. Niestety, moja starsza platforma testowa odmówiła współpracy. Dokładniej chodzi tu o... klawiaturę, a jak wiadomo bez niej to tak samo jak bez ręki :). Mówiąc ściślej z wersjami z 2010 roku nie chce ona poprawnie działać. Po oględzinach, kilkudniowych medytacjach oraz konsultacji z bardziej zaawansowanymi użytkownikami tego systemu, okazało się, ze jest to wina najprawdopodobniej jądra, ponieważ w innych nowszych dystrybucjach Linuksa także występował ten problem. Nie mając dużo czasu, postanowiłem sięgnąć po trochę starszą wersję, ale za to w pełni obsługującą klawiaturę.

Pozostaje jeszcze odpowiedzieć na pytanie dlaczego Linux, a nie Windows. Sprawa jest banalna – pierwszy z nich obsługuje wszystkie z testowanych systemów plików, a drugi tylko dwa – fat32 oraz NTFS. Zapewne znajdą się jeszcze bardziej dociekliwi czytający, którzy chcieli by spytać dlaczego Ubuntu, a nie na przykład Debian, Mandriva, czy Gentoo. Szczerze powiedziawszy jakoś najbardziej do gustu przypadł mi właśnie Ubuntu, który chyba jest najłatwiejszy w obsłudze.

Metodologia testów:

Aby wyeliminować błąd różnego czasu dostępu do różnych obszarów dysku twardego, podzieliłem dysk na cztery partycje:

1. o rozmiarze 30 GB w systemie plików NTFS (nie biorąca udział w testach)

2. o rozmiarze 1,5 GB jako partycja wymiany dla systemu Linux (SWAP)

3. o rozmiarze 20 GB w systemie plików ext4

4. o rozmiarze 25 GB na której testowałem systemy plików

Dane kopiowałem z partycji trzeciej na czwartą. Jeżeli dane kompresowałem lub dekompresowałem, odbywało się to na partycji testowej – czwartej.

Każdą partycję formatowałem z użyciem danego systemu plików przy użyciu programu GParted 0.7.0 w wersji LiveCD (opierającej się o Linuksa Debian).

Wykorzystane systemy plików

Wykorzystałem większość dostępnych w GPartedzie systemów plików. Zdecydowałem, że nawet pokrótce nie będę ich opisywać, ponieważ powielał bym czyjąś pracę, a przy tym pewien okres czasu poszedł by na marne (zawsze lepiej zająć się czymś bardziej wartościowym). Myślę, że najlepszym źródłem wiedzy o poszczególnych systemach plików będzie polskojęzyczna Wikipedia, gdzie po kliknięciu na dany system plików, hiperłącze przeniesie Was do odpowiedniego hasła w encyklopedii. Warto jednak zaznaczyć, z jakich systemów operacyjnych dane systemy plików się wywodzą.

• ext2 - Linux

• ext3 - Linux

• ext4- Linux

• fat32 - Windows

• btrfs - Linux

• hfs+(link do Wikipedii w wersji angielskiej) - MacOS

• jfs - OS/2

• NTFS - Windows

• reiserfs - Linux

• xfs – IRIX (odmiana Unixa)

Każdy z systemów plików był testowany na domyślnym rozmiarze bloku.

W testach nie wzięły udziału:

• fat16 - ze względu na nowszą wersję fat32, która pojawiła się w  teście

• hfs - ponieważ obsługuje on partycji do 2 GB (w teście została użyta partycja o wielkości 25 GB)

• exfat (fat64) i inne mniej popularne - gdyż program GParted go nie obsługuje

• reiser4 – brak obsługi przez Linuksa Ubuntu (i wielu innych systemów  operacyjnych)

• ufs ze względu na brak możliwości sformatowania dysku w tym formacie plików (choć GParted go obsługuje)

Testy

Odczyt danych

Pierwszy z testów obrazował teoretyczną prędkość transferu odczytu danych. Do jego wykonania posłużył mi terminal i polecenie sudo hdparm -t /dev/sda6. Uzyskany wynik obrazował ilość danych odczytanych w czasie 3 sekund (czasami minimalnie więcej). Uzyskana wartość była wynikiem podzielenia ilości odczytanych danych, przez czas w którym zostało to wykonane.

Widzimy, że w tym teście większość systemów plików oferuje podobny transfer odczytu danych. Jedynie ponad błąd pomiarowy wyróżnia się fat32, który okazał się najgorszy w całej stawce oraz NTFS i reiserfs, które okazały się wydajniejsze niż pozostałe. Warto zaznaczyć, że ten drugi dosyć znacznie odstaje od konkurentów, uzyskując wynik o 17% większy niż pozostałe systemy plików.

Zapis danych

Do testu zapisu danych wykorzystałem trzy próbki. Do pierwszej próbki należał jeden plik o wielkości odpowiadającej płycie DVD. W skład drugiej próbki wchodziła dużo średniej wielkości plików, których średni rozmiar wynosił około 5 MB. Trzecia próbka składała się z bardzo dużej liczby bardzo małych plików – o wielkości około 11 KB.

Podczas zapisu jednego dużego pliku, systemy plików podzieliły się na dwie grupy. Do pierwszej z nich należały systemy plików o czasie zapisu w okolicach 210 – 250 sekund, natomiast do drugiej z około dwukrotnie większym czasem zapisu - 420 – 450 sekund. Do tej lepszej grupy należały takie systemy plików jak unixowy xfs, wszystkie trzy exty, jfs (wywodzący się z systemu OS/2) oraz btrfs. Najgorzej poradziły sobie windowsowskie systemy plików – fat32 i NTFS, reiserfs oraz MacOS-owy hfs+.

W drugim teście przedstawiającym kopiowanie mniejszych plików nie widać aż tak skokowej różnicy, jak to miało miejsce w poprzednim teście. Do grona wydajniejszych systemów plików należą xfs, exty, btrfs, jfs oraz co ciekawe fat32, który w poprzednim teście należał raczej do tej wolniejszej stawki. Z zapisem średniej próbki najgorzej sobie poradził NTFS, hfs+ oraz reiserfs.

Ostania próbka w teście zapisu plików okazała się chyba najbardziej wymagającą. Najlepiej poradził sobie z nią reiserfs oraz o dziwo fat32. Trochę wolniej próbkę zapisywały exty, btrfs, jfs, NTFS oraz xfs. Zdecydowanie najgorzej poradził sobie hfs+, który wymagał ponad pół godziny (a więc trzy razy więcej niż pozostali konkurenci ) na zapis wielu bardzo małych plików. Warto zauważyć, że systemy plików z „rodziny” ext ułożyły się w odwrotnej kolejności niż mogłoby się to w teorii wydawać, a więc od teoretycznie najmniej wydajnego do najbardziej wydajnego.

Skanowanie plików antywirusem

Pliki skanowałem programem antywirusowym avast! Linux Home Edition w wersji 1.3.0, którego sygnatury wirusów pochodziły z 6 listopada 2010 roku (nie aktualizowałem ich podczas testu). Do testu skanowania plików antywirusem wykorzystałem ostatnią próbkę plików z testu zapisu danych.

W teście na szybkość skanowania danych, systemy plików po raz kolejny podzieliły się na dwie grupy. Do tej mniej wydajniejszej należy NTSF oraz hfs+ (któryś raz z kolei), natomiast do tej bardziej wydajniejszej pozostałe - czyli reiserfs, btrfs, exty, fat32, xfs oraz jfs. Warto zauważyć, że reiserfs po raz drugi świetnie się sprawdził na operacjach przy małych plikach. Co ciekawe i tutaj exty „ułożyły się” odwrotnie niż mogłoby się wydawać.

Kompresja i dekompresja plików

Do testu obrazującego szybkość kompresji i dekompresji danych posłużyło mi 27 plików z drugiej próbki zapisu danych. W teście wykorzystałem program 7z, którym kompresowałem pliki w formacie 7z, przy użyciu normalnego poziomu kompresji i metody LZMA. Do rozpakowywania plików także posłużył mi program 7z.

Widać, że i tym razem systemy plików podzieliły się na dwie grupy - na hfs+ i resztę konkurentów. Warto zauważyć, że podczas operacji na średnich plikach po raz kolejny na czele stawki stoi xfs, a tuż obok niego ext 3 i ext4. Oprócz wcześniej wspomnianego hfs+, najgorzej poradził sobie ext2 oraz NTFS.

W kolejnym teście kompresji danych systemy plików, tym razem także podzieliły się na hfs+ i resztę. Na czele stawki stoi ext3, btrfs i xfs, który świetnie się sprawdza przy testach na plikach średniej lub dużej wielkości. Najgorzej, oprócz nieszczęsnego hfs+, poradził sobie ext2 i reiserfs.

Podczas dekompresji kilkunastu plików różnicę między poszczególnymi systemami plików są dosyć wyraźne. Do grona najwydajniejszych należą wszystkie trzy exty, które na wykresie występują w kolejności od teoretycznie najbardziej wydajnego do najmniej wydajnego. Najgorzej w całej stawce poradził sobie reiserfs, hfs+ oraz NTFS.

W teście dekompresji ponownie najlepiej poradziły sobie systemy plików z „rodziny” ext, choć między nimi pojawił się także btrfs. Najgorszymi, po raz kolejny okazały się reiserfs, hfs+, NTFS oraz co ciekawe xfs, który podczas kompresji plików stał raczej na czele stawki.

Podsumowanie

Ciężko jednoznacznie odpowiedzieć na pytanie, który system plików jest najwydajniejszy, ponieważ jest kilka systemów plików pretendujących do tego miejsca. Niewątpliwie podczas operacjach na małych plikach bardzo dobry okazuje się system reiserfs. Niestety warto zaznaczyć, że mało kto w większości pracuje na małych plikach. Dużo częściej zwykły użytkownik pracuje właśnie na średnich lub dużych plikach, gdzie ten system plików okazuje się mało wydajny. Jeżeli biorąc pod uwagę testy z częściej wykorzystywanymi plikami, a więc ze średnimi i dużymi, to tutaj bardzo dobre okazują się takie systemy plików jak ext4, ext3 oraz xfs. Czy są one godne polecenia? Myślę, że raczej tak, ponieważ w większości testów stały one na wysokim miejscu w stawce. Warto zaznaczyć, ze xfs nie jest systemem plików pierwotnie stworzonym dla Linuksa, ale dla Unixa.

Pozostaje jeszcze zastanowić się dlaczego NTFS okazuje się mniej wydajny od teoretycznie gorszego fat32. Dzieje się tak gdyż w Linuksie nie jest on jeszcze poprawnie obsługiwany, w odróżnieniu od fata32. Prawdopodobnie w testach wykonanych w systemie Windows XP, Vista lub 7 NTFS wypadł by zdecydowanie lepiej, ale nie można by było przeprowadzić testów innych systemów plików.

Niewątpliwie na wyniki testów wpłynął nie pierwszej nowości dysk twardy, a w testach kompresji i dekompresji dodatkowo także mało wydajny na obecne czasy procesor. Być może na mojej wydajniejszej platformie testowej, poszczególne wyniki wydajności systemów plików wypadłyby trochę inaczej.