Najszybszy system plików Linux na dyskach gontowych

Istnieje duże zainteresowanie napędami gontowymi. Dzięki temu ścieżki danych są tak blisko siebie, że nie można zapisywać na jednej ścieżce bez blokowania kolejnej. Może to zwiększyć pojemność o około 20%, ale powoduje problemy ze wzmocnieniem zapisu. Trwają prace nad systemami plików zoptymalizowanymi dla dysków Shingled, na przykład patrz: https://lwn.net/Articles/591782/

Niektóre gontowe dyski, takie jak archiwum Seagate 8 TB, mają obszar pamięci podręcznej dla losowych zapisów, umożliwiając przyzwoitą wydajność w ogólnych systemach plików. Dysk może być nawet dość szybki przy niektórych typowych obciążeniach, do około 200 MB / s zapisów. Należy się jednak spodziewać, że w przypadku przepełnienia losowej pamięci podręcznej zapisu wydajność może ulec pogorszeniu. Przypuszczalnie niektóre systemy plików lepiej zapobiegają przypadkowym zapisom w ogóle lub wzorom losowych zapisów, które mogą przepełnić pamięć podręczną zapisu znajdującą się na takich dyskach.

Czy główny system plików w jądrze Linuksa jest lepszy w unikaniu obniżenia wydajności dysków gontowych niż ext4?

Intuicyjnie skonstruowane systemy plików typu „kopiuj przy zapisie” i „loguj” mogą poprawić wydajność gontowych dysków poprzez zmniejszenie liczby przypadkowych zapisów. Testy porównawcze nieco to potwierdzają, jednak te różnice w wydajności nie są specyficzne dla dysków z półpasiec. Występują również na nieuzbrojonym dysku używanym jako element sterujący. W związku z tym przejście na dysk gontowy może nie mieć większego związku z wyborem systemu plików.

System plików nilfs2 dawał całkiem dobrą wydajność na dysku SMR. Stało się tak, ponieważ przydzieliłem całą partycję 8 TB, a test porównawczy napisał tylko ~ 0,5 TB, więc program czyszczący nilfs nie musiał działać. Kiedy ograniczyłem partycję do 200 GB, testy porównawcze nilfs nawet się nie zakończyły. Nilfs2 może być dobrym wyborem pod względem wydajności, jeśli naprawdę używasz dysku „archiwizującego” jako dysku archiwum, w którym przechowujesz wszystkie dane i migawki zapisane na dysku na zawsze, ponieważ wtedy nilfs cleaner nie musi się uruchamiać.

Rozumiem, że ST8000AS0002-1NA17Zdysk Seagate 8 TB, którego użyłem do testu, ma ~ 20 GB pamięci podręcznej. Wprowadziłem zmianę domyślnych ustawień serwera plików Filebench, tak aby zestaw testów wynosił ~ 125 GB, większy niż obszar nienazwiązanej pamięci podręcznej:

set $meanfilesize=1310720
set $nfiles=100000
run 36000

Teraz aktualne dane. Liczba operacji mierzy „ogólną” wydajność serwera plików, podczas gdy ms / operacja mierzy opóźnienie losowego dołączania, i może być wykorzystana jako przybliżony wskaźnik wydajności losowych zapisów.

$ grep rand *0.out | sed s/.0.out:/\ / |sed 's/ - /-/g' |  column -t
SMR8TB.nilfs   appendfilerand1   292176ops 8ops/s   0.1mb/s   1575.7ms/op    95884us/op-cpu [0ms - 7169ms]
SMR.btrfs      appendfilerand1  214418ops  6ops/s   0.0mb/s  1780.7ms/op  47361us/op-cpu  [0ms-20242ms]
SMR.ext4       appendfilerand1  172668ops  5ops/s   0.0mb/s  1328.6ms/op  25836us/op-cpu  [0ms-31373ms]
SMR.xfs        appendfilerand1  149254ops  4ops/s   0.0mb/s  669.9ms/op   19367us/op-cpu  [0ms-19994ms]
Toshiba.btrfs  appendfilerand1  634755ops  18ops/s  0.1mb/s  652.5ms/op   62758us/op-cpu  [0ms-5219ms]
Toshiba.ext4   appendfilerand1  466044ops  13ops/s  0.1mb/s  270.6ms/op   23689us/op-cpu  [0ms-4239ms]
Toshiba.xfs    appendfilerand1  368670ops  10ops/s  0.1mb/s  195.6ms/op   19084us/op-cpu  [0ms-2994ms]

Ponieważ Seagate ma 5980 obr./min, można naiwnie oczekiwać, że Toshiba będzie o 20% szybsza. Te testy porównawcze pokazują, że są one około 3 razy (200%) szybsze, więc testy te uderzają w gont karę wydajności. Widzimy, że dysk Shingled (SMR) wciąż nie może być zgodny z wydajnością ext4 na dysku bez gontów (PMR). Najlepsza wydajność była z nilfs2 z partycją 8 TB (więc odkurzacz nie musiał działać), ale nawet wtedy był znacznie wolniejszy niż Toshiba z ext4.

Aby wyjaśnić powyższe testy porównawcze, może pomóc normalizacja ich w stosunku do wydajności ext4 na każdym dysku:

                ops     randappend
SMR.btrfs:      1.24    0.74
SMR.ext4:       1       1
SMR.xfs:        0.86    1.98
Toshiba.btrfs:  1.36    0.41
Toshiba.ext4:   1       1
Toshiba.xfs:    0.79    1.38

Widzimy, że na dysku SMR btrfs ma większość przewagi nad ogólnymi opsami, które ma na ext4, ale kara za losowe dołączanie nie jest tak dramatyczna jak stosunek. Może to doprowadzić do przejścia do btrfs na dysku SMR. Z drugiej strony, jeśli potrzebujesz losowych dołączeń o niskim opóźnieniu, ten test porównawczy sugeruje, że chcesz xfs, szczególnie w SMR. Widzimy, że chociaż SMR / PMR może wpływać na wybór systemu plików, biorąc pod uwagę obciążenie, które optymalizujesz, wydaje się ważniejsze.

Przeprowadziłem również test porównawczy na poddaszu. Czas trwania poddasza (na partycjach pełnego dysku 8 TB SMR) wynosił:

ext4:  1 days 1 hours 19 minutes 54.69 seconds
btrfs: 1 days 40 minutes 8.93 seconds
nilfs: 22 hours 12 minutes 26.89 seconds

W każdym przypadku repozytoria poddasza posiadały następujące statystyki:

                       Original size      Compressed size    Deduplicated size
This archive:                1.00 TB            639.69 GB            515.84 GB
All archives:              901.92 GB            639.69 GB            515.84 GB

Dodanie drugiej kopii tego samego dysku o pojemności 1 TB na strych zajęło 4,5 godziny w każdym z tych trzech systemów plików. Surowy zrzut testów porównawczych i smartctlinformacji znajduje się na stronie: http://pastebin.com/tYK2Uj76 https://github.com/gmatht/joshell/tree/master/benchmarks/SMR

Jeśli korzystasz rsync z napędu SMR, upewnij się, że system plików jest zamontowany read-onlylub ma noatimeopcję.

W przeciwnym razie dysk SMR będzie musiał zapisać znacznik czasu dla każdego pliku odczytanego przez rsync, co spowoduje znaczne obniżenie wydajności (z około 80 Mb / s do 3-5 Mb / s tutaj) i hałas związany z zużyciem / klikaniem.

Jeśli masz już uruchomione zadanie rsync o niskiej wydajności, nie musisz go zatrzymywać, możesz ponownie zainstalować źródłowy system plików

sudo mount -o remount,ro  /path/to/source/fs

Efekt nie będzie widoczny natychmiast, bądź cierpliwy i poczekaj 10 do 20 minut, aż dysk zakończy zapisywanie wszystkich danych nadal w swoich buforach. Ta rada jest wypróbowana i przetestowana.

Może to również obowiązywać podczas rsyncwczytywania na dysk SMR, tj. Gdy system plików próbuje zaktualizować znacznik czasu po pełnym zapisaniu pliku na dysku. To drżące sekwencyjne obciążenie i ogromne pasma danych są ciągle przepisywane, przyczyniając się do zużycia napędu. Pomocne mogą być :

sudo mount -t fs_type -o rw,noatime device /path/to/dest/fs

Należy to zrobić przed uruchomieniem rsync; inne czynniki mogą uczynić tę opcję nieistotną, tj. niebuforowana aktualizacja FAT / MFT, równoległe zapisy, jeśli system plików jest zoptymalizowany głównie pod kątem dysków SSD itp.

Spróbuj użyć dd bs=32Msystemu plików, a następnie zmienić jego rozmiar w docelowym systemie SMR, jeśli mimo to chcesz wykonać kopię zapasową pełnego systemu plików (nie trzeba go montować i uruchamiać rsync, aby przetransportować każdy plik w tym przypadku).

Rzeczywistym używanym sprzętem był dysk konsumencki SMR 8 TB zarządzany przez Seagate. Twój przebieg może się różnić w zależności od innego sprzętu.