Skutecznie usuwaj pliki 10M + z ZFS

Napisałem błędny program, który przypadkowo utworzył około 30 milionów plików w / tmp. (Błąd został wprowadzony kilka tygodni temu i tworzył kilka podkatalogów na sekundę). Mogłem zmienić nazwę / tmp na / tmp2, a teraz muszę usunąć pliki. System to FreeBSD 10, główny system plików to ZFS.

W międzyczasie jeden z dysków w lustrze zepsuł się i wymieniłem go. Napęd ma dwa dyski SSD 120 GB.

Oto pytanie: wymiana dysku twardego i ponowne uruchomienie całego układu zajęło mniej niż godzinę. Usuwanie plików / tmp2 to inna historia. Napisałem inny program do usuwania plików, który może usunąć tylko 30-70 podkatalogów na sekundę. Usunięcie wszystkich plików zajmie 2-4 dni.

Jak to możliwe, że resilverowanie całej macierzy zajmuje godzinę, a usunięcie z dysku zajmuje 4 dni? Dlaczego mam tak słabą wydajność? 70 usunięć na sekundę wydaje się bardzo bardzo słabą wydajnością.

Mógłbym ręcznie usunąć i-węzeł dla / tmp2, ale to nie zwolni miejsca, prawda?

Czy może to być problem z ZFS, dyskami twardymi?

Usunięcia w ZFS są drogie. Tym bardziej, jeśli masz włączoną deduplikację w systemie plików (ponieważ usuwanie deduplikacji plików jest kosztowne). Migawki również mogą skomplikować sprawy.

Lepiej jest usunąć /tmpkatalog zamiast zawartych w nim danych.

Jeśli /tmpjest to system plików ZFS, usuń go i utwórz ponownie.

Jak to możliwe, że resilverowanie całej macierzy zajmuje godzinę, a usunięcie z dysku zajmuje 4 dni?

Rozważ budynek biurowy.

Usunięcie wszystkich komputerów, mebli i elementów mocujących ze wszystkich biur na wszystkich piętrach zajmuje dużo czasu, ale pozostawia biura natychmiast nadające się do użytku przez innego klienta.

Wyburzenia całego budynku z RDX jest dużo szybsza, ale następny klient jest całkiem prawdopodobne, aby narzekać jak przewiewny jest to miejsce.

Tutaj dzieje się wiele rzeczy.

Po pierwsze, wszystkie nowoczesne technologie dyskowe są zoptymalizowane pod kątem przesyłania zbiorczego. Jeśli musisz przenieść 100 MB danych, zrobią to znacznie szybciej, jeśli będą w jednym ciągłym bloku, a nie rozproszeni po całym miejscu. Dyski SSD bardzo tu pomagają, ale nawet wolą dane w sąsiadujących blokach.

Po drugie, resilvering jest dość optymalny, jeśli chodzi o operacje dyskowe. Odczytujesz ogromny ciągły fragment danych z jednego dysku, robisz na nim szybkie operacje procesora, a następnie przepisujesz go w innym dużym ciągłym kawałku na inny dysk. Jeśli dojdzie do awarii zasilania, nic wielkiego - po prostu zignorujesz dane ze złymi sumami kontrolnymi i będziesz postępował jak zwykle.

Po trzecie, usuwanie pliku jest bardzo wolne . ZFS jest szczególnie zły, ale praktycznie wszystkie systemy plików są wolno usuwane. Muszą modyfikować dużą liczbę różnych fragmentów danych na dysku i odpowiednio je mierzyć (tj. Czekać), aby system plików nie został uszkodzony w przypadku awarii zasilania.

Jak to możliwe, że resilverowanie całej macierzy zajmuje godzinę, a usunięcie z dysku zajmuje 4 dni?

Resilvering to coś, w czym dyski są naprawdę szybkie, a usuwanie to coś, w czym dyski są wolne. Na megabajt dysku wystarczy odrobina resilveringu. W tym miejscu może znajdować się tysiąc plików, które należy usunąć.

70 usunięć na sekundę wydaje się bardzo bardzo słabą wydajnością

To zależy. Nie byłbym tym zaskoczony. Nie wspominałeś, jakiego typu dysku SSD używasz. Nowoczesne dyski SSD Intel i Samsung są całkiem dobre w tego rodzaju operacjach (odczyt-modyfikacja-zapis) i będą działać lepiej. Tańsze / starsze dyski SSD (np. Corsair) będą wolne. Decydującym czynnikiem jest liczba operacji we / wy na sekundę (IOPS).

ZFS jest szczególnie powolny, aby usunąć rzeczy. Zwykle wykonuje usuwanie w tle, więc nie widzisz opóźnienia. Jeśli robisz ich ogromną liczbę, nie może tego ukryć i musi cię opóźnić.

Dodatek: dlaczego usuwanie jest powolne?

• Usunięcie pliku wymaga kilku kroków. Metadane pliku muszą zostać oznaczone jako „usunięte”, a ostatecznie muszą zostać odzyskane, aby można było ponownie wykorzystać miejsce. ZFS to „system plików o strukturze dziennika”, który działa najlepiej, jeśli tylko tworzysz rzeczy, nigdy ich nie usuwasz. Struktura dziennika oznacza, że ​​jeśli coś usuniesz, w dzienniku będzie luka, więc inne dane muszą zostać ponownie uporządkowane (zdefragmentowane), aby wypełnić lukę. Jest to niewidoczne dla użytkownika, ale ogólnie powolne.
• Zmiany należy wprowadzić w taki sposób, aby w razie awarii zasilania system plików pozostawał spójny. Często oznacza to czekanie, aż dysk potwierdzi, że dane naprawdę znajdują się na nośniku; dla dysku SSD może to zająć dużo czasu (setki milisekund). Efektem netto jest to, że jest o wiele więcej księgowości (tj. Operacje dyskowe I / O).
• Wszystkie zmiany są niewielkie. Zamiast czytać, pisać i kasować całe bloki flash (lub cylindry na dysk magnetyczny), musisz zmodyfikować trochę jednego z nich. Aby to zrobić, sprzęt musi odczytać cały blok lub cylinder, zmodyfikować go w pamięci, a następnie ponownie zapisać na nośniku. To zajmuje dużo czasu.

Jak to możliwe, że resilverowanie całej macierzy zajmuje godzinę, a usunięcie z dysku zajmuje 4 dni?

Jest to możliwe, ponieważ dwie operacje działają na różnych warstwach stosu systemu plików. Resilvering może działać na niskim poziomie i tak naprawdę nie musi patrzeć na pojedyncze pliki, kopiując jednocześnie duże porcje danych.

Dlaczego mam tak słabą wydajność? 70 usunięć na sekundę wydaje się bardzo bardzo słabą wydajnością.

To musi robić dużo księgowości ...

Mógłbym ręcznie usunąć i-węzeł dla / tmp2, ale to nie zwolni miejsca, prawda?

Nie wiem dla ZFS, ale gdyby mógł się automatycznie z tego zregenerować, prawdopodobnie wykonałby te same operacje, które już robisz, w tle.

Czy może to być problem z ZFS, dyskami twardymi?

Czy zfs scrubcoś mówi

Usuwanie dużej liczby plików nigdy nie jest naprawdę szybką operacją.

Aby usunąć plik w dowolnym systemie plików, musisz odczytać indeks pliku, usunąć (lub oznaczyć jako usunięty) wpis pliku w indeksie, usunąć wszelkie inne metadane powiązane z plikiem i oznaczyć miejsce przydzielone dla pliku jako nie używany. Należy to zrobić indywidualnie dla każdego pliku do usunięcia, co oznacza, że ​​usunięcie wielu plików wymaga dużej liczby małych operacji we / wy. Robienie tego w sposób zapewniający integralność danych w przypadku awarii zasilania powoduje jeszcze większe obciążenie.

Nawet bez osobliwości, którą wprowadza ZFS, usunięcie 30 milionów plików zwykle oznacza ponad sto milionów oddzielnych operacji we / wy. To będzie trwać długo, nawet przy szybkim SSD. Jak wspomnieli inni, konstrukcja ZFS dodatkowo pogłębia ten problem.

Ian Howson daje dobrą odpowiedź na pytanie, dlaczego jest wolny.

Jeśli usuniesz pliki równolegle, możesz zauważyć wzrost prędkości z powodu usunięcia, możesz użyć tych samych bloków, a tym samym zaoszczędzić przepisywania tego samego bloku wiele razy.

Więc spróbuj:

find /tmp -print0 | parallel -j100 -0 -n100 rm

i sprawdź, czy to działa lepiej niż twoje 70 operacji usuwania na sekundę.

Bardzo proste, jeśli odwrócisz swoje myślenie.

1. Zdobądź drugi dysk (wydaje się, że już to masz)

2. Skopiuj wszystko z dysku A na dysk B za pomocą rsync, z wyjątkiem katalogu / tmp. Rsync będzie wolniejszy niż kopia blokowa.

3. Uruchom ponownie, używając dysku B jako nowego woluminu rozruchowego

4. Sformatuj dysk A.

Spowoduje to również defragmentację dysku i nowy katalog (dobrze, defragmentacja nie jest tak ważna z dyskiem SSD, ale linearyzacja plików nigdy niczego nie zaszkodzi)

Masz 30 milionów wpisów na nieposortowanej liście. Skanujesz listę w poszukiwaniu wpisu, który chcesz usunąć, i usuwasz go. Teraz masz tylko 29 999 999 wpisów na liście nieposortowanej. Jeśli wszystkie są w / tmp, dlaczego po prostu nie uruchomić ponownie?

Edytowane w celu odzwierciedlenia informacji w komentarzach: Opis problemu: Usunięcie większości, ale nie wszystkich , 30M + nieprawidłowo utworzonych plików w / tmp zajmuje dużo czasu.
Problem 1) Najlepszy sposób na usunięcie dużej liczby niechcianych plików z / tmp.
Problem 2) Zrozumienie, dlaczego tak wolno jest usuwać pliki.

Rozwiązanie 1) - / tmp jest resetowany do pustego podczas rozruchu przez większość dystrybucji * nix. FreeBSD nie jest jednak jednym z nich.
Krok 1 - skopiuj ciekawe pliki gdzie indziej.
Krok 2 - Jako root

 $ grep -i tmp /etc/rc.conf  
 clear_tmp_enable="YES" # Clear /tmp at startup.  

Krok 3 - uruchom ponownie.
Krok 4 - zmień opcję clear_tmp_enable z powrotem na „Nie”.
Niechciane pliki zniknęły, ponieważ ZFS na FreeBSD ma funkcję, że „Zniszczenie zbioru danych jest znacznie szybsze niż usunięcie wszystkich plików znajdujących się w zbiorze danych, ponieważ nie wymaga skanowania wszystkich plików i aktualizacji wszystkich odpowiednich metadanych. „ więc podczas uruchamiania wystarczy zresetować metadane dla zestawu danych / tmp. To jest bardzo szybkie.

Rozwiązanie 2) Dlaczego jest tak wolne? ZFS to wspaniały system plików, który zawiera takie funkcje, jak stały dostęp do katalogu w czasie. Działa to dobrze, jeśli wiesz, co robisz, ale dowody wskazują, że OP nie jest ekspertem ZFS. OP nie wskazał, w jaki sposób próbowali usunąć pliki, ale zgaduję, powiedziałbym, że zastosowali odmianę „find regex -exec rm {} \;”. Działa to dobrze z małymi liczbami, ale nie jest skalowane, ponieważ trwają trzy operacje szeregowe 1) pobierz listę dostępnych plików (zwraca 30 milionów plików w kolejności mieszania), 2) użyj wyrażenia regularnego, aby wybrać następny plik do usunięcia, 3 ) powiedz systemowi operacyjnemu, aby znalazł i usunął ten plik z listy 30 milionów. Nawet jeśli ZFS zwraca listę z pamięci i jeśli „find” buforuje go, regex nadal musi zidentyfikować następny plik do przetworzenia z listy, a następnie powiedzieć systemowi operacyjnemu, aby zaktualizował swoje metadane, aby odzwierciedlić tę zmianę, a następnie zaktualizować listę, aby nie była ponownie przetwarzana.