Dlaczego rm jest wolny na zewnętrznym napędzie pamięci masowej (podłączonym przez USB, typu fuseblk) z 50 GB plików?

21

Próbowałem użyć rsnapshot do tworzenia kopii zapasowych, ale nie mogę go używać . Chociaż jest w stanie różnicować katalog (50 GB) i duplikować go (twarde linkowanie każdego pliku) w ciągu kilku minut, a cały katalog mogę cp w około pół godziny, jego usunięcie zajmuje znacznie ponad godzinę. Nawet przy bezpośrednim użyciu rm -rfvuważam, że wykonanie pojedynczego pliku może zająć do pół sekundy, podczas gdy polecenia cpi są linkwykonywane natychmiast.

Dlaczego rm jest taki wolny? Czy istnieje szybszy sposób rekurencyjnego usuwania linków? Nie ma dla mnie sensu, że kopiowanie pliku powinno zająć mniej czasu niż usunięcie go.

System plików, nad którym pracuję, to zewnętrzny dysk pamięci, podłączony przez USB i typu fuseblk (co myślę, że oznacza, że ​​to NTFS). Mój komputer działa pod Ubuntu Linux.

Wyjście z góry:

Cpu(s):  3.0%us,  1.5%sy,  0.0%ni, 54.8%id, 40.6%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   8063700k total,  3602416k used,  4461284k free,   557604k buffers
performance rm external-hdd Benubird
źródło
1
Montowanie, ponieważ fuseblknie oznacza, że ​​dysk jest NTFS, oznacza jedynie, że jest on zamontowany jako urządzenie FUSE. To może być prawie wszystko.
Chris Down
1
@ChrisDown Prawda, ale wiem, że jest to albo NTFS, albo ext3, i jestem prawie pewien, że jeśli byłby to ext3, byłby on zamontowany jako taki przez mount bez żadnych argumentów.
Benubird
1
To zależy, ile plików jest w katalogu (nie powiedziałeś ile), a w szczególności NTFS zwalnia tylko z plikami> 3K w katalogu. Prawie każdy inny system plików jest znacznie bardziej wydajny. Zobacz wszystkie inne posty w SO / SE na temat wpływu liczby plików na wydajność systemu plików.
smci

Odpowiedzi:

28

Ostatecznie, bez względu na to, co robisz, rmmusi działać unlinkna każdym pliku, który chcesz usunąć (nawet jeśli wywołujesz rm -rkatalog macierzysty). Jeśli jest wiele plików do usunięcia, może to zająć dużo czasu.

Po uruchomieniu są dwa szczególnie czasochłonne procesy rm -r:

  1. readdir, śledzony przez,
  2. liczba połączeń z unlink.

Znalezienie wszystkich plików, a następnie przejrzenie każdego pojedynczego pliku, aby go usunąć, może zająć naprawdę bardzo długo.

Jeśli okaże się, że jest to „bezużyteczne”, ponieważ powoduje, że katalog nie nadaje się do użytku przez pewien czas, rozważ przeniesienie katalogu nadrzędnego przed jego usunięciem. Spowoduje to zwolnienie tej nazwy do ponownego użycia przez program, bez nadmiernej niedogodności.

Zakładając, że system plików to tak naprawdę system plików NTFS (nie jest to jasne z twojego pytania), system plików NTFS jest na ogół dość powolny w usuwaniu dużych plików. Możesz rozważyć użycie bardziej odpowiedniego systemu plików do swoich celów (nowsze systemy plików ext mają całkiem niezłą wydajność usuwania, jeśli nie masz innych szczególnych potrzeb). Sam FUSE również nie jest szczególnie szybki. Możesz rozważyć, czy możesz to zrobić w sposób, który nie korzysta z BEZPIECZNIKA.

Chris Down
źródło
2
+1 Naprawdę wiele zależy od dokładnego systemu plików - wiele z nich działa naprawdę dobrze w niektórych operacjach, a jednocześnie jest powolny w stosunku do innych (często dotyczy to tworzenia plików vs. usuwania vs. dostępu do danych).
peterph
15

Dlaczego rm jest taki wolny? Nie mam pojęcia. Ale znam szybszy sposób:

mkdir blank
rsync -a --delete blank/ test/

Aktualizacja: Ta odpowiedź na Serverfault zawiera kilka wyjaśnień. Wygląda na to, że rsync usuwa pliki w określonej kolejności, która powoduje, że drzewo systemu plików pozostaje zrównoważone i nigdy nie potrzebuje ponownego równoważenia. rm po prostu usunie pliki i spowoduje wiele przywracania równowagi podczas ich usuwania. Istnieją pewne informacje o zrównoważenie tutaj .

rjmunro
źródło
1
Czy porównałeś to z porównaniem rm -rf? rsyncnadal ma unlink()wszystkie pliki w test/, i to prawdopodobnie zajmuje czas.
MattBianco
Nie przeprowadziłem formalnej analizy porównawczej, ale spróbowałem po przeczytaniu czyichś testów, a różnica była znaczna. Nie mogę już znaleźć tego postu, ale ta odpowiedź na temat błędu serwera zawiera wyjaśnienie i źródło jeszcze szybszego usuwania programu.
rjmunro
Ale najszybsza metoda musi być unlink(2)w katalogu (i pamiętać, aby zrobić to fsckpóźniej) ...
MattBianco,
Fakt jest faktem. Właśnie go wyliczyłem i jest prawie dwa razy szybszy. Po przeczytaniu kodu GNU coreutils rm nawet nie zastanawiam się…
Dominik George,
1

Cóż, kiedyś miałem podobny problem z twoim. Odkryłem, że twoje „wa” jest wysokie, możesz użyć

iostat -x 1

sprawdzenie, czy zużycie dysku jest wysokie, jeśli tak, oznacza to, że dysk jest dość zajęty. Sprawdź, czy niektóre inne procesy ciągle zapisują na dysk.

Dla uproszczenia użyj

vmstat 1

aby sprawdzić, czy b jest wysokie lub r < b . To wskazuje na coś złego. W twojej sytuacji myślę, że dysk IO jest oryginalnym powodem.

fibonacci
źródło