Usuwanie miliardów plików z katalogu, jednocześnie obserwując postęp


36

Mam katalog o pojemności 30 TB z miliardami plików, które są formalnie wszystkimi plikami JPEG. Usuwam każdy folder plików w ten sposób:

sudo rm -rf bolands-mills-mhcptz

To polecenie po prostu działa i nie pokazuje niczego, czy działa, czy nie.

Chcę zobaczyć, jak usuwa pliki lub jaki jest obecny status polecenia.


19
Brak odpowiedzi: czasami tworzenie kopii zapasowych rzeczy, które chcesz zachować, formatowanie i przywracanie rzeczy, które chcesz zachować, jest szybsze. Inne odpowiedzi: unix.stackexchange.com/questions/37329/...
Eric Towers

2
Jeśli chcesz tylko pomysłu postępu, zamiast wiedzieć, które konkretne pliki zostały usunięte, możesz uruchomić polecenie „df / dev / sd_whthing_the_drive_is”.
jamesqf

11
Jak skończyłeś z miliardami plików w jednym katalogu?
Wyścigi lekkości z Moniką

1
@MichaelHampton Ale jeśli pliki nie są oddzielnym zestawem danych, może to zająć dużo czasu. (na ZFS) serverfault.com/questions/801074/…
v7d8dpo4

5
Miliardy plików, co? Spróbować rm -ri. Będzie fajnie!
OldBunny2800,

Odpowiedzi:


98

Możesz użyć rm -vdo rmusunięcia jednej linii na plik. W ten sposób widać, że rmrzeczywiście działa usuwanie plików. Ale jeśli masz miliardy plików, zobaczysz, że rmnadal działa. Nie będziesz miał pojęcia, ile plików zostało już usuniętych, a ile pozostało.

Narzędzie pvmoże pomóc w oszacowaniu postępu.

http://www.ivarch.com/programs/pv.shtml

Oto jak można powoływać rmsię pvz Przykâadowa

$ rm -rv dirname | pv -l -s 1000 > logfile
562  0:00:07 [79,8 /s] [====================>                 ] 56% ETA 0:00:05

W tym wymyślonym przykładzie powiedziałem pv, że są 1000pliki. Dane wyjściowe pvpokazują, że 562 są już usunięte, czas, który upłynął, wynosi 7 sekund, a oszacowanie do ukończenia to 5 sekund.

Niektóre wyjaśnienia:

  • pv -lsprawia, pvże liczyć według nowego wiersza zamiast bajtów
  • pv -s numberinformuje, pvco to jest suma, dzięki czemu można oszacować.
  • Przekierowanie logfilena końcu służy do czystego wydruku. W przeciwnym razie linia statusu z pvzostanie pomieszana z wyjściem z rm -v. Bonus: będziesz mieć plik dziennika tego, co zostało usunięte. Ale uwaga, plik stanie się ogromny. Możesz również przekierować do, /dev/nulljeśli nie potrzebujesz dziennika.

Aby uzyskać liczbę plików, możesz użyć tego polecenia:

$ find dirname | wc -l

Może to również zająć dużo czasu, jeśli istnieją miliardy plików. Możesz także użyć pvtutaj, aby zobaczyć, ile się to liczyło

$ find dirname | pv -l | wc -l
278k 0:00:04 [56,8k/s] [     <=>                                              ]
278044

Tutaj napisano, że liczenie 278 tys. Plików zajęło 4 sekundy. Dokładna liczba na końcu ( 278044) jest wyjściem z wc -l.

Jeśli nie chcesz czekać na zliczanie, możesz zgadnąć liczbę plików lub użyć pvbez oszacowania:

$ rm -rv dirname | pv -l > logfile

W ten sposób nie będziesz mieć oszacowania do ukończenia, ale przynajmniej zobaczysz, ile plików zostało już usuniętych. Przekieruj do, /dev/nulljeśli nie potrzebujesz pliku dziennika.


Nitpick:

  • Czy naprawdę potrzebujemy sudo?
  • zwykle rm -rwystarczy usunąć rekurencyjnie. nie ma potrzeby rm -f.

5
Niezłe wykorzystanie pv, zakładając, że policzenie miliardów plików nie jest zbyt drogie ;-). (Może to zająć prawie tyle samo czasu, ile rmpowinno się zmierzyć!)
Stephen Kitt

7
@StephenKitt To co naprawdę denerwuje mnie (i wielu innych ludzi) na temat użyteczności plików systemu Windows: to zawsze , bez wątpienia, zlicza liczbę i rozmiary plików przed usunięciem których, o ile dysk jest znacznie wolniejszy niż procesor, zajmuje prawie jak tak długo jak rzeczywiste usunięcie!
wizzwizz4,

@ wizzwizz4 Rzeczywiście! Jest to coś więcej niż to, że IIRC - sprawdza, czy może usunąć wszystko przed usunięciem czegokolwiek , aby zwiększyć szanse, że usunięcie będzie „wszystko albo nic”. Wiele lat temu napisałem sterownik systemu plików dla systemu Windows, z którymi musieliśmy sobie poradzić, w tym kilka związanych ze sposobem, w jaki Explorer usuwa, ale nie pamiętam szczegółów. (Pamiętam, że utworzenie folderu wymaga zapisania i usunięcia pliku w nowym folderze!)
Stephen Kitt

7
@StephenKitt Może się mylę, ale czy to nie wąskie gardło, oprócz dostępu do dysku, wyjścia terminala? Wierzę, że pvodświeża pasek postępu tylko raz na sekundę, pomimo jego wkładu. Zatem terminal musi wyświetlać tylko jedną linię zamiast tony co sekundę. pvwystarczy zwiększyć licznik dla każdej napotkanej nowej linii; to musi być szybsze niż zawijanie linii, a co więcej do wyświetlania linii w terminalu. Myślę, że uruchamianie w pvten sposób powoduje, że usuwanie plików jest szybsze niż po prostu rm -rv.
JoL

1
@skywinderrm -rv dirname | pv -l -s $(find dirname | wc -l) > logfile
lesmana

28

Sprawdź odpowiedź lesmany , jest znacznie lepsza niż moja - szczególnie ostatni pvprzykład, który nie potrwa dłużej niż pierwotne milczenie, rmjeśli podasz /dev/nullzamiast logfile.

Zakładając, że rmobsługuje tę opcję (prawdopodobnie dzieje się tak, ponieważ używasz Linuksa), możesz uruchomić ją w trybie pełnym -v:

sudo rm -rfv bolands-mills-mhcptz

Jak zauważyło wielu komentujących, może to być bardzo wolne ze względu na ilość danych generowanych i wyświetlanych przez terminal. Zamiast tego możesz przekierować dane wyjściowe do pliku:

sudo rm -rfv bolands-mills-mhcptz > rm-trace.txt

i obserwuj rozmiar rm-trace.txt.


5
To może spowolnić usuwanie, ponieważ wszystkie dane wyjściowe są generowane i renderowane do terminala :)
rackandboneman

2
Oczywiście spowolni. Zapisanie miliardów linii do pliku nie następuje w czasie zero.
user207421,

23

Inną opcją jest obserwowanie zmniejszania się liczby plików w systemie plików. W innym terminalu uruchom:

watch  df -ih   pathname

Liczba użytych i-węzłów zmniejsza się w miarę rmpostępu. (Chyba że pliki miały przeważnie wiele łączy, np. Jeśli drzewo zostało utworzone za pomocą cp -al). Śledzi to postęp usuwania pod względem liczby plików (i katalogów). dfbez -ibędzie śledzić pod względem zajmowanej przestrzeni.

Możesz także uruchomić, iostat -x 4aby zobaczyć operacje We / Wy na sekundę (jak również KiB / s, ale nie jest to bardzo istotne w przypadku operacji We / Wy na czystych metadanych).


Jeśli zastanawiasz się nad plikami, rmnad którymi obecnie pracujesz, możesz dołączyć stracedo niego plik i obserwować, jak unlink()wywołania systemowe (i getdents) wywołują szum na twoim terminalu. np sudo strace -p $(pidof rm). Możesz ^cprzejść oderwanie, rmnie przerywając go.

Zapominam, czy rm -rzmienia katalog na drzewo, które usuwa; jeśli tak, możesz na to spojrzeć /proc/<PID>/cwd. Jej /proc/<PID>/fdsiła często katalogiem fd otwarte, więc można patrzeć na to, aby zobaczyć, co rmproces jest aktualnie patrzysz.


2
df -ihto naprawdę fajny tani sposób na obserwowanie rmpostępów.
Stephen Kitt,

BTW, to nie działa na BTRFS, gdzie liczba użytych i-węzłów jest zawsze równa zero. :( To samo dotyczy FAT32, ale prawdopodobnie nie masz miliardów plików na /bootpartycji systemowej EFI.
Peter Cordes

4

Chociaż wszystkie powyższe odpowiedzi są w użyciu rm, w rmrzeczywistości może być dość powolne w usuwaniu dużej liczby plików, jak niedawno zauważyłem podczas wyodrębniania ~ 100 000 plików z archiwum .tar w rzeczywistości zajmowało mniej czasu niż ich usuwanie. Chociaż tak naprawdę nie odpowiada to na zadane pytanie, lepszym rozwiązaniem problemu może być zastosowanie innej metody usuwania plików, na przykład jednej z pozytywnych odpowiedzi na to pytanie .

Moją ulubioną metodą jest użycie rsync -a --delete. Uważam, że ta metoda działa wystarczająco szybko, aby była warta łatwości użycia w stosunku do najbardziej uprzywilejowanej odpowiedzi na to pytanie , w której autor napisał program C, który należy skompilować. (Zauważ, że spowoduje to wyprowadzenie każdego przetwarzanego pliku na standardowe wyjście, podobnie jak rm -rv; może to spowolnić proces o zaskakującą ilość. Jeśli nie chcesz tego wyjścia, użyj rsync -aq --deletelub przekieruj wyjście do pliku.)

Autor tej odpowiedzi mówi:

Program usunie teraz (w moim systemie) 1000000 plików w ciągu 43 sekund. Najbliżej tego programu był rsync -a --delete, który zajął 60 sekund (co również wykonuje usuwanie w kolejności, ale nie wykonuje wydajnego wyszukiwania katalogu).

Przekonałem się, że jest to wystarczająco dobre dla moich celów. Również potencjalnie ważne z tej odpowiedzi, przynajmniej jeśli używasz ext4:

Z góry należy usunąć katalog, którego dotyczy problem, i ponownie go później. Katalogi tylko zwiększają swój rozmiar i mogą pozostać słabej wydajności nawet z kilkoma plikami w środku ze względu na rozmiar katalogu.


huh, spodziewałbym się rmi / lub find --deletebyć skuteczny. Interesujący punkt dotyczący usuwania w kolejności sortowania, aby uniknąć ponownego równoważenia b-drzewa podczas usuwania. Nie jestem pewien, ile to dotyczy innych systemów plików. XFS również nie jest świetny z milionami plików na katalog. IDK o BTRFS, ale mam wrażenie, że może to być dobre dla tego rodzaju rzeczy.
Peter Cordes,

Czy ten drugi cytat nie zależy od rodzaju systemu plików ...
Menasheh

@Menasheh Dobrze, edytowałem to w swojej odpowiedzi.
Hitechcomputergeek,

3

Jedną rzeczą, którą możesz zrobić, to uruchomić rmproces w tle (bez danych wyjściowych, aby nie został spowolniony), a następnie monitorować go na pierwszym planie za pomocą prostej (a) komendy:

pax> ( D=/path/to/dir ; rm -rf $D & while true ; do
...>   if [[ -d $D ]] ; then
...>     echo "$(find $D | wc -l) items left"
...>   else
...>     echo "No items left"
...>     break
...>   fi
...>   sleep 5
...> done )

27912 items left
224 items left
No items left

pax> _

find/wcKombi można zastąpić dowolnym narzędziem w stanie podać jednostki chcesz.


(a) Cóż, stosunkowo proste, w porównaniu do, powiedzmy, fizyki jądrowej, hipotezy Riemanna lub tego, co kupić mojej żonie na Boże Narodzenie :-)


0

Jakiś czas temu napisałem coś, aby wydrukować szybkość drukowania linii. Możesz uruchomić rm -rfv | ./counteri będzie drukować linie na sekundę / min. Chociaż nie jest to bezpośredni postęp, dostarczy ci informacji zwrotnych na temat tempa postępu, może rmwędrował do sieciowego systemu plików lub podobnego?

Link do kodu znajduje się tutaj:

http://www.usenix.org.uk/code/counter-0.01.tar.gz

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.