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?
źródło
df -h
izpool list
izfs list
.rm -rf /tmp2
nie wykona pracy?/tmp
powinien być systememtmpfs
plików i jest przechowywany w pamięci.Odpowiedzi:
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ąć
/tmp
katalog zamiast zawartych w nim danych.Jeśli
/tmp
jest to system plików ZFS, usuń go i utwórz ponownie.źródło
ionice
, zakładając, że FreeBSD je ma) podczas usuwania.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.
źródło
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.
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ąć.
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?
źródło
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.
To musi robić dużo księgowości ...
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
zfs scrub
coś mówiźródło
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.
źródło
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:
i sprawdź, czy to działa lepiej niż twoje 70 operacji usuwania na sekundę.
źródło
Bardzo proste, jeśli odwrócisz swoje myślenie.
Zdobądź drugi dysk (wydaje się, że już to masz)
Skopiuj wszystko z dysku A na dysk B za pomocą rsync, z wyjątkiem katalogu / tmp. Rsync będzie wolniejszy niż kopia blokowa.
Uruchom ponownie, używając dysku B jako nowego woluminu rozruchowego
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)
źródło
zfs send/recv
(skopiować na poziomie bloku) wszystkie inne systemy plików oprócz głównego systemu plików (gdzie w tym przypadku znajduje się / tmp) i ręcznie skopiować pozostałe dane do głównego systemu plików (oczywiście z wyjątkiem / tmp).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
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.
źródło