FreeBSD vs Linux: wydajność systemu plików

1. Cele i cele
2. Uczestnicy testów
3. O platformie testowej
4. Obiekty testowe
5. Wyniki
6. Ufs
7. Ext2fs
8. Ext3fs
9. Reiserfs
10. Xfs
11. Jfs
12. Wnioski

Alexey Fedorchuk
2004

Przy wszystkich niezasłużonych zaletach FreeBSD powszechnie uznaje się, że sam nie może pochwalić się wysoką wydajnością operacji na plikach. To prawda, że ​​istnieje opinia, że ​​nie jest to spowodowane powolnością systemu plików, a jedynie domyślnym trybem jego używania. Nie mogłem jednak znaleźć żadnych danych ilościowych i dlatego postanowiłem przeprowadzić własne małe badania.

Cele i cele

Na początku postawiłem sobie bardzo ograniczone zadanie - mierzenie prędkości nowoczesnego systemu plików FreeBSD, UFS2, w różnych trybach montowania. Jak wiadomo, domyślnie jest zamontowany w tzw. tryb noasync, w którym zmiany w metadanych pliku są zapisywane na dysku synchronicznie, a do rzeczywistych danych używane jest zapis asynchroniczny, czyli buforowanie. Co początkowo stawia UFS2 w niekorzystnej sytuacji (pod względem szybkości) w porównaniu z Linuksem, gdzie domyślnie dla większości systemów plików obsługiwanych przez ten system operacyjny jako macierzysty jest czysty tryb asynchroniczny - z buforowaniem nie tylko danych, ale także metadanych.

Jednakże, teoretycznie, w FreeBSD istnieje tryb czysto asynchroniczny, chociaż jego użycie jest bardzo odradzane we wszystkich oficjalnych dokumentach projektu, co przyczynia się do spadku niezawodności. Z pewnością jest to prawdą w przypadku serwerów, ale nie wydaje się tak istotne dla komputerów wyposażonych w bespereboynikami (a moim zdaniem skromny bespereboynik jest nieodzownym atrybutem każdej maszyny uniksowej, zwłaszcza w postradzieckiej rzeczywistości). Tak więc istniało naturalne pragnienie - spojrzenia i zachowania się UFS2 w trybie asynchronicznym.

Natychmiast zauważam, że pierwsze wyniki pomiarów były nieco nieoczekiwane i przynajmniej dla mnie nie do końca jasne. Dlatego też, w celu wyjaśnienia sytuacji, postanowiłem porównać je z pomiarami dokonanymi w podobnych warunkach dla ext2fs w systemie Linux. Cóż, a potem - stało się ciekawsze porównanie z innymi systemami plików Linux. I wreszcie pojawiło się pytanie, jak te systemy operacyjne współpracują ze swoimi systemami plików. Ponieważ obsługa Linuksa UFS2 nie jest obecnie zaimplementowana (a nawet włączenie obsługi UFS nie jest prostym zadaniem), musiałem ograniczyć się do pomiaru tylko dla ext2fs w FreeBSD. Tak więc i zdecydowany

Uczestnicy testów

Pierwszym uczestnikiem był oczywiście UFS2, utworzony z domyślnymi parametrami sysinstall (rozmiar bloku - 16384 bajty, rozmiar fragmentu - 2048), z włączeniem trybu SoftUpdates przewidzianego przez to narzędzie. I zamontowany w tym samym domyślnym trybie, czyli częściowo asynchroniczny (opcja -o noasync, domyślnie wykonywana podczas wykonywania polecenia montowania).

Ponadto, w oparciu o ogólne rozważania, możliwe było założenie, że na szybkość operacji na plikach może mieć również wpływ opcja -o noatime, która uniemożliwia aktualizację czasu ostatniego dostępu do plików. Następnie przetestowano tryb czysto asynchroniczny (opcja -o async). I wreszcie połączenie obu opcji, z których teoretycznie należy oczekiwać maksymalnej wydajności.

Przedmiotem porównania były rodzime systemy plików Linux. Przede wszystkim oczywiście był to klasyczny ext2fs, montowany w dwóch trybach - domyślnym iw trybie -o noatime.

Następnie - jego wersja dziennika, ext3fs. Dostępne są dla niego trzy tryby użytkowania - pełne kronikowanie (opcja -o dane = dziennik), które rejestruje operacje nie tylko z metadanymi pliku, ale także ich danymi, standardowe kronikowanie częściowe (opcja -o dane = uporządkowane, przy których dane i metadane zgrupowane w pojedynczy blok transakcji) i tryb zapisu wstecznego, w którym nie jest rejestrowane żadne dane. W tym przypadku odmówiłem użycia opcji -o noatime (szczerze mówiąc, po prostu z lenistwa - chociaż, jak wynika z wyników, ta opcja nie dałaby niczego zasadniczo nowego).

Dalej - ReiserFS, najbardziej pretensjonalny (i być może najbardziej popularny wśród użytkowników Linuksa) system plików z księgowaniem. Tutaj, oprócz domyślnego, ponownie spróbowałem odmówić aktualizacji atime - i, jak pokazała praktyka, nie jest na próżno.

Zrobiłem to samo z XFS - pomiary na nim wykonano w trybie domyślnym iw trybie z opcją -o noatime. I wreszcie, jeśli chodzi o JFS, ograniczyłem się do trybu domyślnego - skoro nigdy nie korzystałem z tego systemu praktycznie, niewiele o nim wiem i przyciągałem go wyłącznie do porównania.

Wszystkie systemy plików zostały utworzone przy użyciu odpowiednich narzędzi (mke2fs dla ext2fs i ext3fs, mkreiserfs i mk.xfs dla tych samych systemów plików, jfs_mkfs dla JFS) z domyślnymi parametrami. Wyjątkiem był XFS, dla którego wielkość grupy alokacji i wielkość magazynu zostały wybrane zgodnie z zaleceniami Daniela Robbinsa (wielkość magazynu - 32 MB, co najmniej jedna grupa alokacyjna dla 4 GB miejsca na dysku przydzielonego dla tego systemu plików).

W każdym pomiarze prędkości operacji na plikach zawsze pojawia się trudne pytanie - co właściwie mierzymy, wydajność systemu plików lub tylko fizyczna prędkość dysku, a także wydajność systemu operacyjnego z odpowiednimi interfejsami dysku. Dlatego trzeba powiedzieć kilka słów.

O platformie testowej

Pomiary wykonano na żelazie pod ręką, które zawierało:

• Procesor Pentium-4 / 2,53 GHz, FSB 533, bez HT;
• Płyta główna Albatron PX845PE na tym samym chipsecie, w wersji z dodatkowym kontrolerem ATA RAID / SerialATA Promise FastTrack 376 (choć nieużywana);
• 1 GB pamięci RAM (2 × 512 PC-2700, sprzedawane pod marką „podobno Samsung”);
• Dysk twardy Seagate Barracuda 40 GB, interfejs ParallelATA, 7200 obr./min, połączony jako pojedynczy kanał z pierwszym kanałem standardowego kontrolera ATA z południowego mostu ICH4.

Inne komponenty, takie jak CD-ROM (pojedynczy na drugim kanale IDE), nie mają w tym przypadku żadnej wartości.

Dysk ma 4 partycje podstawowe. Pierwszy, o pojemności 30 MB z systemem plików ext2fs, służył jako boot i przenosił tylko GRUB (i jądro Linuksa). Druga sekcja została zdefiniowana jako wycinek BSD, aw nim na systemie plików UFS2 mieściła się FreeBSD 5.2.1. Trzecia sekcja została zadeklarowana jako DOS Extended i nosiła Archlinux 0.6 (jądro 2.6.6). Szczegóły ich podziału, jak również systemy plików, nie mają znaczenia w tym kontekście.

Unikając nieporozumień, zauważam, że w obu systemach operacyjnych dysk działał w trybie normalnym UDMA100, co zostało określone przez narzędzia atacontrol w FreeBSD i hdparm w systemie Linux.

A jednak: FreeBSD został poddany procedurze make world z flagami optymalizacji -O1 i -march = pentium4. Jądro ponownie złożone w oparciu o bardzo lekki GENERIC (z wyjątkiem obsługi wszystkich brakujących, takich jak SCSI i karty sieciowe), zostało skompilowane z flagą -O2 pod tym samym Pentium-4. W przypadku Archlinux użyto wstępnie skompilowanego (z repozytorium projektu - bieżącego) jądra, zmontowanego, podobnie jak cały system, z flagami -O2 -march = i686.

Jednak wszystko, co powiedziano w poprzednim akapicie, nie może mieć dramatycznego wpływu na działanie operacji na plikach. A zatem dla nas ważna jest tylko czwarta sekcja podstawowa, o rozmiarze 5,5 GB, która została poddana wszelkim rodzajom nękania. Po co, po przypisaniu odpowiedniego identyfikatora (odpowiednio 4.2BSD lub Linux native), utworzono na nim systemy plików wymienione w poprzedniej sekcji, które zostały zamontowane z określonymi opcjami. Na nich umieszczono już dane, które reprezentowały

Obiekty testowe

Konfiguruję pomiary do celów osobistych, dlatego najbardziej interesowały mnie operacje z danymi, z którymi mam do czynienia regularnie. Są to: a) tablice mieszanych danych (ilustrujące je teksty i grafiki), b) tablice z ogromnej liczby bardzo małych plików (takich jak drzewo portów FreeBSD i podobne systemy zarządzania pakietami z dystrybucji Linux Source), oraz c) duże pliki z płyt CD i powyżej. Zgodnie z tym podniosłem obiekty testowe.

Po pierwsze, był to katalog moich materiałów roboczych - pliki w formacie zwykłego tekstu i html z ilustracjami w formatach gif, tiff, jpeg, png, których rozmiar wahał się od kilku kilobajtów do pierwszych dziesiątek megabajtów. Aby ożywić obraz, rozcieńczyłem go plikami dźwiękowymi MPEG (od 1,5 do 6 MB każdy). W rezultacie pierwsza tablica testowa wyniosła łącznie 830 MB.

Drugim obiektem było improwizowane drzewo portów FreeBSD z 6 maja 2004 r., O objętości 24,2 MB, będące wynikiem „rozładunku”, co dało katalog 124 MB. Jego specyfika polega na tym, że tworzy go ogromna (ponad 100 tys.) Liczba plików, których przeważająca wielkość to kilkaset bajtów.

Wreszcie trzecim obiektem był plik AVI w rozmiarze CD - 693 MB.

Nic lepszego niż mierzenie czasu kopiowania tych tablic, nie wymyśliłem. Oznacza to, że katalog danych został skopiowany przez polecenie takie jak

$ cp data newdata

z późniejszym zniszczeniem katalogu docelowego

$ rm -Rf newdata

i mierzenie czasu każdej operacji przez wyprowadzenie polecenia daty przed i po nim. Zrobiłem to samo z dużym plikiem. Wstępnie wdrożony zespół portów do tarballa

$ tar xzvf ports.tar.gz

czas, który również był mierzony - to nie tylko szybkość dekompresji i niearchiwizowania, w zależności od prędkości procesora, ale także szybkość, z jaką wynik jest włączany do systemu plików. Aby ułatwić życie, operacje na każdym obiekcie były wykonywane z prostego skryptu widoku.

date >> file_of_result && command1 && date >> file_of_result && ... date >> file_of_result &&

Wszystkie trzy testy dla każdego systemu plików w każdym trybie przeprowadzono trzy razy. Pod koniec cyklu system plików został odmontowany i ponownie zamontowany przed powtórzeniem. Jako wynik przyjęto średnią arytmetyczną trzech wartości.

Wyniki

Wyniki pomiarów prędkości wszystkich operacji wykonywanych na trzech obiektach przedstawiono w tabeli i na rys. 1-3. Jednostki miary - odpowiednio sekundy, mniejsze wartości wszędzie odpowiadają najlepszym wskaźnikom. Które rozważymy kolejno dla wszystkich systemów plików.

Ufs

Zacznijmy od tego, który służył jako główna przyczyna tej notatki - z UFS2. Pamiętam, że był montowany sekwencyjnie w czterech trybach - domyślnym, z włączeniem opcji -o noatime, w trybie czysto asynchronicznym (opcja -o async) i wreszcie, z włączeniem obu tych opcji. Teoretycznie rzecz biorąc, w tej kolejności szybkość operacji na plikach powinna wzrosnąć. Co widzimy w praktyce?

Tabela Wyniki pomiaru (w sekundach) szybkości operacji na plikach w różnych systemach plików

Test

Pracuj z danymi

Pracuj z portami

Duży plik

Tryb FS +

Kopiuj

Usuń

Untar

Kopiuj

Usuń

Kopiuj

Usuń

UFS, domyślnie

211

7

189

255

92

104

0

Ufs noatime

210

7

194

333

99

102

0

UFS, async

211

8

201

352

99

103

0

UFS, oba

209

6

202

344

98

103

0

Ext2, FreeBSD

222

25

280

309

222

150

1

Ext2, domyślnie

71

6

90

68

7

45

0

Ext2, noatime

73

6

93

68

7

46

0

Ext3, dziennik

123

6

134

58

6

98

1

Ext3, zamówiony

81

15

107

115

17

50

16

Ext3, zapis zwrotny

91

7

107

68

51

53

1

Reiser, domyślnie

100

2

59

51

7

44

1

Reiser, noatime

89

2

71

26

7

47

1

XFS, domyślnie

95

9

76

83

41

48

0

Noatime Xfs

97

9

80

74

42

49

0

Domyślnie Jfs

132

13

267

160

19

91

0

Wyniki kopiowania tablicy danych (patrz rys. 1) we wszystkich czterech trybach można uznać za prawie identyczne. Wydaje się, że nieco lepsze wyniki pozwalają na odmowę aktualizacji atime, jednak zarówno absolutnie, jak i względnie różnica jest znikoma. W każdym razie włączenie trybu asynchronicznego nie zapewnia żadnego skoku prędkości, którego można się spodziewać na podstawie ogólnych rozważań. Szybkość usuwania mieszanej tablicy plików jest również mniej więcej taka sama: nieco lepsze wyniki przy włączeniu obu opcji są najprawdopodobniej w granicach błędu eksperymentalnego (dokładność danych wyjściowych polecenia daty mieści się w ciągu jednej sekundy).

Rys. 1. Pracuj z tablicą mieszanych danych

Jeszcze bardziej imponujący wykres pokazuje wyniki pracy z drzewem portów (rys. 2). Teoretycznie można by oczekiwać gwałtownego wzrostu prędkości w asynchronicznym przetwarzaniu ogromnej liczby małych plików. Jednak w praktyce widzimy odwrotny obraz: najlepsze wyniki zarówno podczas wdrażania tarballa, jak i podczas kopiowania drzewa portów, a także podczas usuwania, są uzyskiwane tylko domyślnie, synchronicznie dla trybu metadanych. Co więcej, w przypadku kopiowania jego przewaga wygląda dość istotnie: włączenie dowolnej z dodatkowych opcji (a zwłaszcza obu) powoduje spadek szybkości tej operacji o 30-50%.

Rys. 2. Praca z drzewem portów

Kopiowanie dużego pliku jest jedyną operacją, w której tryb domyślny wydaje się pokazywać najgorsze wyniki (Rys. 3). Jednak różnica w wartościach bezwzględnych i względnych wygląda śmiesznie. I najprawdopodobniej znowu istnieje powód naturalnej zmienności błędu. Cóż, usunięcie pojedynczego pliku, jak można się spodziewać, zachodzi niemal natychmiastowo (chociaż, jak zobaczymy później, nie jest to oczywiste).

Rys. 3. Pracuj z dużym plikiem

Osobiście widzę jedno wyjaśnienie obserwowanego obrazu: tryb asynchroniczny podczas montowania nowoczesnego systemu plików FreeBSD jest niczym więcej jak fikcją, a tak naprawdę metadane są przetwarzane synchronicznie. W każdym razie możesz być szczęśliwy tylko dla twórców tego systemu operacyjnego: oferowany przez nich domyślny tryb montowania zapewnia lepsze lub praktycznie gorsze wyniki niż jakiekolwiek inne, które wymagają dodatkowych opcji i, odpowiednio, niepotrzebnych gestów.

Wadą tego jest to, że rezerwy na poprawę szybkości operacji na plikach w FreeBSD nie mogą być wykryte. Zobaczmy teraz, co tracimy, odmawiając na korzyść Linuksa z wieloma systemami plików.

Ext2fs

Zacznijmy od klasyków gatunku - tradycyjnych ext2fs. Podczas kopiowania tablicy mieszanych danych, pokazuje godną pozazdroszczenia prędkość, ponad trzy razy większą niż prędkość tej operacji w UFS2, przy porównywalnej (ale formalnie lepszej) szybkości usuwania. Jeśli zignorujemy liczby bezwzględne, zobaczymy, że włączenie opcji noatime i tutaj, wbrew oczekiwaniom, nie daje niczego pod względem wydajności.

Ten sam obraz jest obserwowany w teście z drzewem portów. Zarówno rozmieszczenie tarballa, jak i kopiowanie katalogu małych plików oraz jego usuwanie występują równie szybko, niezależnie od tego, czy ostatni czas dostępu jest aktualizowany, czy nie. W odniesieniu do UFS2, to bardzo „szybkie” jest wyrażone przez dwa (dla operacji „rozładunku”), a nawet pięć (dla kopiowania) jest przewagą wielokrotną. Usunięcie drzewa portów jest na ogół o ponad rząd wielkości szybsze - w rzeczywistości jest tak szybkie jak usunięcie tablicy mieszanej.

Podczas pracy z dużym plikiem nie ma też niespodzianek: jest on szybko kopiowany (ponad dwa razy szybciej niż w UFS2) i jest usuwany niemal natychmiast.

Ogólnie rzecz biorąc, musimy z żalem stwierdzić, że jeśli chodzi o szybkość, UFS2 nie był nawet zbliżony do ext2fs, bez względu na powód (w zasadzie dla użytkowników komputerów, te wyjaśnienia są cholerną żarówką). Dlatego interesujące jest, czy ext2fs pokaże się z tą samą dobrą stroną także w FreeBSD?

Ponownie, niestety, nie manifestuje się. Montowany domyślnie, w tym systemie operacyjnym demonstruje tylko katastrofalną prędkość. Dokładniej, jego całkowita nieobecność - wyniki wszystkich testów są gorsze (i dla portów i dużego pliku - dużo gorsze) niż dla drogiego UFS2. Znaczące jest to, że nie oszczędza nawet dobrej szybkości usuwania plików, dzięki czemu udało się wyróżnić nawet przy kasowaniu pojedynczego dużego pliku.

Oczywiście ext2fs ze swej natury nie mogą być tak wiarygodne jak UFS2. A jego potencjalna skłonność do niszczenia (i zdarzały się sytuacje, w których ext2f prawie gwarantowały awarię po awarii systemu) próbuje skompensować dostosowanie do kronikowania, wkręcając w niezależny system plików - ext3fs. Zobaczmy, jak drogo jest za to płacić pod względem prędkości.

Ext3fs

Jak już wspomniano, ext3fs ma trzy tryby montowania - z pełnymi metadanymi i kronikowaniem danych, pełnym kronikowaniem metadanych i częściowymi danymi (w rzeczywistości nie jest to dość ścisłe, ale proponuję zwrócić się do źródeł specjalnych w celu uzyskania szczegółowych informacji o trybie zamawiania) i bez żadnego księgowania dane ogólnie. Oficjalna dokumentacja ext3fs stwierdza, że ​​niezawodność systemu spada w kolejności transferu, a wręcz przeciwnie, prędkość wzrasta. W związku z tym domyślnie ext2fs jest montowany w trybie, który programiści uważają za pośredni pod każdym względem, to znaczy w trybie uporządkowanym.

Nie omawiamy tutaj kwestii niezawodności, ale szybkości ... Podczas kopiowania tablicy mieszanych danych tryb dziennika naprawdę okazuje się najwolniejszy, ale prymat pozostaje za trybem uporządkowanym (a nie zapisem zwrotnym, jak można się spodziewać). Ale skasowanie wyników tej kopii generalnie pokazuje paradoksalny obraz: podczas gdy w trybach dziennika i zapisu wstecznego szybkość usuwania katalogu jest prawdopodobnie szybka (prawie taka sama jak w ext2fs), to w trybie uporządkowanym ta procedura jest wykonywana nieprzyzwoicie powoli (15 sekund przeciwko 6-7, jak widać z tabeli).

Rozważenie pracy z małymi plikami pozostawia uczucie bardzo sprzeczne. Wdrażanie archiwum jest najwolniejsze w trybie pełnego rejestrowania i nieco szybsze (i równe) w obu trybach rejestrowania częściowego. Tryb dziennika jest nieoczekiwanie najlepszy w radzeniu sobie z drzewem portów, tryb zapisu wstecznego jest nieco wolniejszy, a uporządkowanie po prostu nie powiedzie się - szybkość operacji usuwania jest dwa razy niższa niż reszta.

Dalej - więcej: wykres prędkości usuwania drzewa portów jest przeciwieństwem teoretycznie oczekiwanego: genialny wynik w trybie pełnego rejestrowania (6 sekund - nieco lepszy niż w przypadku ext2fs), przeciętny (17 sekund) - w trybie uporządkowanym i najgorszy dla wszystkich systemów plików Linux (51 sekund) - w rzekomo najszybszym trybie zapisu zwrotnego.

Wreszcie, obsługa dużego pliku daje nam kolejną (już oczekiwaną) niespodziankę: rozkład prędkości kopiowania jest taki sam dla drzewa portów (najlepszy wynik jest w trybie uporządkowanym, gorzej, ale zamknięcie jest w trybie zapisu wstecznego i znacznie gorsze w dzienniku, 50, Odpowiednio 53 i 98 sekund). Ale po usunięciu tego największego pliku tryb uporządkowany wyróżnił się jak nikt inny: w tej procedurze zajęło to aż 16 sekund. Nie tylko najgorszy ze wszystkich, ale nie do zniesienia. I jeszcze raz podkreślam, że nie chodzi tu o przypadkową serię, ale o średnią trzech wymiarów, rozdzieloną przez ponowne zamontowanie systemu plików.

Jak zobaczymy później, pod względem szybkości ext3fs wygląda raczej blado na tle innych systemów plików, z którymi działa Linux. Ale w porównaniu z FreeBSD, wciąż zachowuje przewagę we wszystkich pozycjach: dzięki wysiłkom wszystkich trzech trybów kronikowania oryginalne ext2fs nie mogą być zredukowane do poziomu częściowo synchronicznego UFS2. A nawet najgorszy wynik ext3fs podczas pracy z portami pozostaje poza zasięgiem systemu operacyjnego, w którym po raz pierwszy pojawił się pomysł portów.

Jednak mówiąc o portach, pobiegłem nieco dalej. Ponieważ na początku trzeba było zobaczyć, a który system plików zajmuje pierwsze miejsce w pracy z dużą liczbą małych plików?

Reiserfs

Ten system plików został pierwotnie zaprojektowany (w tym), aby skutecznie obsługiwać dużą liczbę małych plików - w szczególności, aby zaoszczędzić miejsce dla nich. Jednak teraz interesuje nas szybkość - i ogólnie wszystkie pliki. Zacznijmy od tablicy mieszanych danych.

I tutaj, po raz pierwszy, widzimy triumf teoretycznych prognoz: umiarkowana prędkość kopiowania naszej tablicy w trybie domyślnym jest zwiększona o 10%, gdy włączony jest tryb noatime - od 100 sekund do 89 (chociaż nie osiąga rekordu). Ale rekord jest bity przez usunięcie skopiowanej tablicy - 2 sekundy w każdym z trybów.

Drzewo portów ... Doskonałe wyniki podczas rozładowywania i kopiowania w trybie domyślnym. Jeśli anulujesz aktualizację atime w pierwszym przypadku, są one nieco gorsze. Ale potem - brawo - kopiowanie tą opcją odbywa się prawie dwukrotnie szybciej niż bez niej; jeszcze nie widzieliśmy takiego wyniku. I znowu, ReiserFS jest blisko rekordu podczas usuwania hańby portowej - kończąc head to head z ext2fs.

I ostatnia niespodzianka z pomysłem Hansa Reisera - kopiowanie dużego pliku pokazuje, że należy do najlepszych, chociaż tutaj wpływ noatime nie ma na to wpływu. Zobaczymy, czy XFS poradzi sobie z tym, a wręcz przeciwnie, był przeznaczony do przechowywania informacji multimedialnych.

Xfs

W ogólnym pliku danych kopiowanie daje wynik zbliżony do średniej harmonicznej, podczas gdy czas potrzebny na ich usunięcie wydaje się nieco zawyżony (9 sekund).

Pracuj z portami - na średnim poziomie w stosunku do „usuwania” i kopiowania. I - nieoczekiwanie długi czas na usunięcie drzewa portów (ponad 40 sekund), zbliżając się do trybu zapisu wstecznego ext3fs „anti-record” (chociaż nadal jest znacznie lepszy niż w przypadku UFS2).

Ale wynik dla dużego pliku (48-49 sekund) nie podobał się: chociaż był jednym z najlepszych, spodziewałem się więcej po „multimedialnym” systemie plików. Chociaż, być może z punktu widzenia SGI, jest to 700 MB - to nie znaczy wiele? A w pocieszeniu - nie odnotowano również błędu podczas usuwania dużego pliku :-).

Jfs

Eponym system plików z księgowaniem nie ma konkurencji w naszych rankingach - przyczyny wymienione powyżej. Wyniki pokazały, że było to całkiem uzasadnione. Bo mamy:

• najgorszy wynik wśród wszystkich systemów plików Linuxa podczas kopiowania tablicy mieszanej i drugiego od końca (po awarii trybu uporządkowanego etx2fs) został usunięty;
• najgorszy wynik „rozłączania” wśród wszystkich rodzimych systemów plików, w tym UFS2; tylko ext2fs z FreeBSD okazały się gorsze - ale przecież od nieznajomego i łapówki są płynne;
• szczerze mówiąc, nie jest genialny czas na usunięcie drzewa portów;
• kopiowanie dużego pliku - zakończ w wąskiej grupie maruderów.

Ogólnie rzecz biorąc, JFS, jedyny system plików obsługiwany przez Linuksa, okazał się porównywalny z szybkością UFS2 (a raczej jego brakiem). Oczywiście nie można wykluczyć, że jego eksperci mogą poprawić wydajność za pomocą dowolnych opcji; W szczególności słyszałem gdzieś, że Linuxowa wersja JFS działa w standardowy sposób prawie w trybie czysto synchronicznym - patrząc na wyniki, można w to uwierzyć. Powtarzam jednak, domyślnie pojawia się on jako najwolniejszy.

Wnioski

Muszę powiedzieć, że przeprowadzone pomiary zasadniczo zmieniły moje pomysły na systemy plików w ogóle (chociaż coś wzmocniły).

W szczególności zawsze podejrzewałam, że oba systemy plików FreeBSD - stary UFS i nowy UFS2 - były gorsze niż moje siostry Linuksa pod względem szybkości. Tak, zazwyczaj jest widoczny i, jak mówią, organoleptycznie. Nie spodziewałem się jednak, że w przypadku UFS2 pod względem ilościowym opóźnienie będzie tak znaczące. Muszę zauważyć, że pomiary, które wykonałem wcześniej dla UFS, po prostu nie wykazały tak uderzającego zahamowania - nawet w odniesieniu do ext2fs (dla ReiserFS, mniejsza luka może być wyjaśniona przez niemowlę, a następnie przez jego wiek). Możliwe, że jest to zwrot zarówno dla adresowania 64-bitowego, jak i dla podwójnych i-węzłów ...

Co więcej, nie spodziewałem się tak dobrych wyników ReiserFS nie tylko dla bardzo małych plików, ale dla wszystkich innych testów. Odbieram więc wszystkie niezbyt dobre słowa, które wcześniej do niej przemówiłem. To prawda, że ​​empirycznie obserwowalne (ale nie ilościowe) zjawisko spadku wydajności na dużych (ponad 100 GB) partycjach znajdujących się na RAID oprogramowania pozostaje niesprawdzone - ale dla wielu użytkowników komputerów stacjonarnych jest to istotne?

Nie pokazał się w oczekiwanym blasku i tak kochany przeze mnie przed XFS. Jednak jest niewiele, gdy musisz pracować z plikami z większą ilością cydushnika, aw tych granicach okazało się, że nie jest szybszy niż ReiserFS.

Ale w tym, co pomogły mi pomiary - był w uprzedzonym (i niekorzystnym) stosunku do ext3fs. I nawet nie jest tak, że przynajmniej część jej reżimu „wyróżniała się” przynajmniej na jednym teście. Niezadowolenie jest spowodowane nieprzewidywalnością jego zachowania w zależności od trybu i charakteru danych. Prawdopodobnie programiści mieli powody, by wyciągnąć wnioski na temat optymalności trybu zamawiania - jednak były one oparte, najwyraźniej, na zadaniach serwera, ale nie na komputerach.

Który system plików powinien wybrać prosty użytkownik pulpitu dla swojej indywidualnej osoby? Moja odpowiedź nie będzie świecić oryginalnością, jeśli oświadczę z całą pewnością: każde warzywo ma swój własny owoc. I nie ma sensu próbować znaleźć systemu, który jest równie szybki do przechowywania drzewa portów (lub ich analogów Linuksa), i do budowania obrazów izo do tworzenia kopii zapasowych, i tak dalej, i tak dalej, i tak dalej.

Na szczęście użytkownik FreeBSD jest wolny od tych udręk - UFS i UFS2 są obiektywnymi realiami przekazanymi mu przez programistów z Berkelean. Tylko on powinien zrozumieć, że przynajmniej podczas pracy z plikami będzie musiał poświęcić szybkość dla harmonii i dokładności używanego systemu. Czy jednak utrata czasu na kopiowanie plików skompensowana przez brak prób z niedopasowaniem wersji bibliotek lub kompilatorów?

Ale użytkownik Linuksa ma coś do złamania. Ponieważ jednoznacznie nie poleciłbym tylko JFS do użytku - i nawet wtedy nie jest faktem, że po przeczytaniu dokumentacji dla wielu puddingów byłbym tak kategoryczny (inna rzecz, że jak dotąd żadna z funkcji tego systemu plików nie może mnie przenieść do takie czytanie, zwłaszcza w języku angielskim).

Nawet jeśli ext3fs nie jest przeze mnie kochany, możesz znaleźć aplikację. W szczególności dla systemu plików root, gdy / var, / usr, / opt są przenoszone z niego do osobnych gałęzi (jeśli jest aktywnie zaangażowany w tę dystrybucję), i oczywiście / home.

Dla pierwszych trzech gałęzi ReiserFS wydaje się odpowiedni. Zwłaszcza jeśli mamy - Zestaw dystrybucyjny oparty na źródle wykorzystujący dowolny system portobrazny. A jeśli chodzi o słowo - będzie to idealne rozwiązanie, gdy drzewo tych portoidów jest renderowane w osobnej gałęzi wewnątrz / usr lub / var. I wciąż pomiary skłoniły mnie do myślenia, że ​​dla / home ReiserFS jest więcej niż odpowiedni - kiedyś, poza XFS, nie rozpoznawałem niczego takiego. Chociaż teraz nie widzę powodu, dla którego szlachcic nie publikowałby swoich danych na XFS - zwłaszcza jeśli nie ma zwyczaju często i w dużych ilościach go usuwać.

Wreszcie, ext2fs nie jest najgorszym wyborem dla wielu użytkowników, którzy nie chcą zawracać sobie głowy tworzeniem wielu partycji i wybieraniem dla nich idealnych systemów plików (zakładając, że istnieje nieprzerwana partycja, oczywiście). I okazuje się to absolutnie niezbędne: a) do wymiany danych z FreeBSD zainstalowanym na tej samej maszynie oraz b) do partycji / boot w przypadku korzystania z multiloadera GRUB. Więc stara kobieta zbyt wcześnie wychodzi, żeby odpisać w obiegu ...