Jaki jest najbardziej wydajny system plików Linux do przechowywania wielu małych plików (HDD, a nie SSD)?

43

Mam drzewo katalogów, które zawiera wiele małych plików i niewielką liczbę większych plików. Średni rozmiar pliku to około 1 kilobajt. W drzewie znajduje się 210158 plików i katalogów (liczba ta została uzyskana przez uruchomienie find | wc -l).

Mały procent plików jest dodawany / usuwany / przepisywany kilka razy w tygodniu. Dotyczy to zarówno małych plików, jak i (niewielkiej liczby) większych plików.

Systemy plików, które wypróbowałem (ext4, btrfs) mają pewne problemy z pozycjonowaniem plików na dysku. Z biegiem czasu fizyczne położenie plików na dysku (nośniki obrotowe, a nie dysk półprzewodnikowy) stają się coraz bardziej losowe. Negatywną konsekwencją tej losowej dystrybucji jest spowolnienie systemu plików (na przykład: 4 razy wolniejsze niż nowy system plików).

Czy istnieje system plików Linux (lub metoda konserwacji systemu plików), która nie cierpi z powodu tego spadku wydajności i jest w stanie utrzymać stabilny profil wydajności na obracającym się nośniku? System plików może działać na Fuse, ale musi być niezawodny.

linux filesystems performance
źródło
Jeśli wiesz, które pliki będą duże / nie zmieniają się bardzo często, a które będą małe / często zmieniające się, możesz chcieć utworzyć dwa systemy plików z różnymi opcjami, bardziej dostosowane do każdego scenariusza. Jeśli potrzebujesz, aby były dostępne, ponieważ były częścią tej samej struktury, możesz wykonać kilka sztuczek za pomocą mount, dowiązań symbolicznych.
Marcin
Jestem cicho zaskoczony, wiedząc, że btrfs (z funkcją kopiowania przy zapisie) był dla ciebie powolny przez pewien czas. Jestem ciekawy, że podzielę się z tobą wynikami, być może pomagając sobie nawzajem w nowym kierunku dostrajania wydajności.
Nikhil Mulley
w Linuksie pojawiło się nowe ZFs online dla zwierząt, dostępne w trybie natywnym i implementacji bezpieczników, w razie czego chciałbyś rzucić okiem.
Nikhil Mulley,
Próbowałem raz ZFS na Linuksie, było dość niestabilne. Udało się dość często całkowicie zablokować system plików. Box działałby, ale dostęp do FS byłby zawieszony.
Patrick
Podobny post serverfault.com/questions/6711
Nikhil Mulley

Odpowiedzi:

47

Wydajność

Napisałem mały test porównawczy ( źródło ), aby dowiedzieć się, jaki system plików działa najlepiej z setkami tysięcy małych plików:

  • utwórz 300000 plików (od 512B do 1536B) z danymi z / dev / urandom
  • przepisz 30000 losowych plików i zmień rozmiar
  • odczytać 30000 plików sekwencyjnych
  • odczytać 30000 losowych plików

  • usuń wszystkie pliki

  • synchronizuj i upuszczaj pamięć podręczną po każdym kroku

Wyniki (średni czas w sekundach, niższy = lepszy):

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

Wynik:
Podczas gdy Ext4 miał dobrą ogólną wydajność, ReiserFS był wyjątkowo szybki w czytaniu plików sekwencyjnych. Okazało się, że XFS działa wolno z wieloma małymi plikami - nie należy go używać w tym przypadku użycia.

Problem fragmentacji

Jedynym sposobem, aby uniemożliwić systemom plików dystrybuowanie plików na dysku, jest utrzymanie partycji tak dużej, jak naprawdę jej potrzebujesz, ale uważaj, aby nie zrobić zbyt małej partycji, aby zapobiec fragmentacji plików. Korzystanie z LVM może być bardzo pomocne.

Dalsza lektura

Arch Wiki ma kilka świetnych artykułów dotyczących wydajności systemu plików:

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices

tafer
źródło
4
Powinieneś określić, z której wersji jądra korzystasz na podstawie tego porównania. XFS otrzymał kilka bardzo znaczących usprawnień prędkości w jednym z ostatnich jąder (myślę, że to 2.6.31, ale nie cytuję o tym).
Patrick
1
btrfs wewnętrznie robi lewą sztuczkę. Przydziela mniejsze fragmenty dysku i umieszcza pliki w tych fragmentach, a następnie przydziela tylko inny fragment dysku, gdy istniejące fragmenty się zapełniają.
psusi
1
Dotyczy to każdego systemu plików. Dlatego aplikacje używają rzeczy takich jak fsync ().
psusi
2
@taffer, tak jest. Transakcje mają taki sam efekt jak dziennik w innych systemach plików: chronią metadane fs. Teoretycznie mogą być używane przez aplikacje w sposób opisany przez Ciebie, ale obecnie nie ma interfejsu API pozwalającego aplikacjom na otwieranie i zamykanie transakcji.
psusi
1
@taffer Twój „ostatni test” pochodzi z kwietnia 2015 roku, ma ponad trzy lata i używa XFS z tylko domyślnymi opcjami. To jest wcześniejsze niż xfsprogs 3.2.3, co sprawia, że ​​XFS v5 jest domyślny i zapewnia wszystkie korzyści. Nie został również sformatowany za pomocą opcji -m finobt = 1, która zmienia zasady działania wydajności XFS z małymi plikami i ciężkimi aktualizacjami metadanych. Nie, nie ma srebrnych kul, ale opieranie się na starych testach porównawczych nie jest mądre, szczególnie gdy główne funkcje zmieniające wydajność zostały zignorowane, niedostępne lub wyłączone.
Jody Lee Bruchon
7

Korzystam z ReiserFS do tego zadania, jest on specjalnie zaprojektowany do obsługi wielu małych plików. Na stronie wiki funtoo jest łatwy do odczytania tekst .

ReiserFS ma również wiele funkcji mających na celu poprawę wydajności małych plików. W przeciwieństwie do ext2, ReiserFS nie przydziela przestrzeni dyskowej w ustalonym jednym k lub czterech k blokach. Zamiast tego może przydzielić dokładny rozmiar, którego potrzebuje.

Baarn
źródło
1
Istnieją również problemy ze stabilnością w ReiserFS - więc RH i SuSE porzuciły FS. Z zasady (BTree-based-FS) BTRFS powinien być porównywalny.
Nils,
0

XFS jest znany z bardzo dobrych wyników w takich sytuacjach. Jest to część tego, dlaczego używamy go w mojej pracy dla naszych sklepów pocztowych (które mogą zawierać setki tysięcy plików w jednym katalogu). Ma lepszą odporność na uszkodzenia niż ReiserFS, jest w dużo szerszym zastosowaniu i jest ogólnie bardzo dojrzałym systemem plików.

Ponadto XFS obsługuje defragmentację online. Mimo że wykorzystuje technikę opóźnionego przydzielania, co skutkuje mniejszą fragmentacją (w porównaniu z innymi systemami plików) na początek.

Patrick
źródło
20
XFS jest znany z bardzo dobrych wyników w takich sytuacjach. [potrzebne źródło]
taffer
8
Ehm, xfs jest szczególnie znany z czegoś przeciwnego: działa naprawdę dobrze z dużymi plikami, ale nie tak dobrze na małych! Spójrz na przykład na ten wyczerpujący test porównawczy (lub przejdź od razu do konkluzji na stronie 10 ^^): ilsistemista.net/index.php/linux-a-unix/…
Levite
1
@ Lewit Myślę, że źle odczytujesz ten raport. Raport bardzo wyraźnie pokazuje, że XFS działa bardzo dobrze w przypadku losowych operacji we / wy. Ale poza tym raport nie odnosi się do rodzaju scenariusza w tym pytaniu, wielu plików. Losowe IO to jedno, duża liczba plików to miejsce, w którym ext * spada na jego twarz.
Patrick
2
Jedynym miejscem, w którym XFS jest naprawdę lepszy, są losowe operacje odczytu / zapisu (nadal wydaje się dziwne, że prawdziwie losowy wzorzec odczytu na dysku mechanicznym może uzyskać 10 MB / s - wydaje mi się to jakaś optymalizacja, która nie leci w prawdziwym świecie (imho)), podczas gdy na stronie 7 pokazuje to, co powiedziałem wcześniej, XFS jest naprawdę dobry w obsłudze dużych plików! Spójrz na strony 3 i 5, zwłaszcza na 3 widać, że radzi sobie z małymi plikami wyraźnie nie tak dobrze jak ext! Naprawdę nie mam nic przeciwko XFS, ale z tego, co można znaleźć wszędzie, nie jest to najlepszy optiom dla wielu małych plików, to wszystko, co mówię!
Levite
5
XFS może być również bardzo powolny, jeśli chodzi o duże pliki, jeśli pliki te są rozszerzane losowo / powoli z małymi fragmentami przez długi czas. (Typowy syslogdwzorzec.) Na przykład po mojej stronie w konfiguracji XFS ponad MD Właśnie zauważyłem, że usunięcie pliku 1,5 GB zajęło 4,75 minuty (!), Podczas gdy dysk był ograniczony limitem 100 transakcji / s przy szybkości zapisu powyżej 2 MB / s. Wpływa to również negatywnie na wydajność innych równoległych operacji we / wy na tym samym dysku, ponieważ dysk jest już maksymalnie wykorzystany. Nigdy nie widziałem czegoś takiego w innych systemach FS (ani nie był testowany w testach porównawczych).
Tino