Lepiej używać lokalnego Rm-rf zamiast ponad NFS?

10

Czy miałoby to znaczną różnicę w czasie, aby zalogować się na komputerze, który ma katalog przed wykonaniem rm -rfw nim katalogu, czy po prostu rm -rfkatalogiem w systemie NFS?

nfs performance steviekm3
źródło

Odpowiedzi:

11

Oczywiście ssh jest lepszy.

Nfs używa złożonego protokołu sieciowego z różnymi zdalnymi wywołaniami procedur i czasami oczekiwania synchronizacji danych. W przypadku ssh nie mają one zastosowania.

Ponadto istnieje wiele zamków. Usuwanie plików w NFS działa w ten sposób:

  1. twoje rmpolecenie daje unlink()syscall
  2. sterownik nfs konwertuje go na żądanie sunrpc i wysyła do serwera nfs
  3. Serwer nfs konwertuje to żądanie sunrpc z powrotem na unlink()wywołanie
  4. wykonuje to unlink()wywołanie po stronie zdalnej
  5. po tym, jak się powiedzie, zwraca klientowi odpowiedź rpc odpowiadającą „w porządku, zrobiono”
  6. sterownik jądra po stronie klienta konwertuje to z powrotem na kod wyjścia 0 unlink()wywołania twojego oryginałurm
  7. rm przechodzi do następnego pliku, goto 1

Teraz ważne jest: między 2-7, rmmusi czekać. Może wysyłać następne unlink()wywołanie asynchronicznie, ale jest to narzędzie jednowątkowe, nie zorientowane na zdarzenie. Nawet gdyby mógł, nadal wymagałoby trudnych flag montowania NFS. Dopóki nie uzyska wyniku, czeka.

Nfs - i każdy sieciowy system plików - jest zawsze znacznie wolniejszy.

W wielu przypadkach możesz wykonać rekursywne usuwanie quasi-nieskończoną prędkością za pomocą sztuczki:

  1. Najpierw przenieś katalog do innej nazwy ( mv -vf oldfilms oldfilms-)
  2. Usuń w tle ( rm -rf oldfilms- &)

Z wielu (ale nie wszystkich) aspektów to usunięcie katalogu będzie wyglądało, jakby miało miejsce praktycznie w czasie zero.

Rozszerzenie: Jak wspomina @ el.pascado w swoim doskonałym komentarzu, właściwie 2-7 musi uruchomić 3x dla każdego pliku:

  • aby ustalić, czy jest to plik, czy katalog (z wywołaniem lstat()syscall),
  • następnie wykonaj odpowiednio. W przypadku zwykłych plików, unlink()w przypadku katalogów opendir(), usuwając wszystkie pliki / katalogi w nim rekurencyjnie, to closedir()w końcu rmdir().
  • na koniec przejdź do następnego wpisu w książce telefonicznej z readdir()połączeniem.

Wymaga to 3 poleceń RPC nfs dla plików i dodatkowych 3 dla katalogów.

peterh - Przywróć Monikę
źródło
2
Sprawa NFS jest jeszcze gorsza. Jak pytanie wspomina -rflagę, rmmusi najpierw sprawdzić, czy plik jest katalogiem ( lstatprzez nfs), otworzyć go ( opendirprzez nfs), przeczytać jego zawartość ( readdirprzez nfs), a dopiero potem wykonać faktyczne usunięcie zgodnie z opisem w odpowiedzi na każdy plik znaleziony w środku i rekursywnie do podkatalogów, zamknij katalog ( closedirprzez nfs), a następnie powtórz dla każdego znalezionego katalogu .
el.pescado
5

Tak. Być może. To zależy. W przypadku niewielkiej liczby plików i katalogów nie zrobiłoby to dużej różnicy.

Zbiorcze wykonywanie plików w katalogu podłączonym do systemu plików NFS jest powolne. Jeśli masz możliwość zalogowania się do samego serwera NFS i zrobienia ich w rzeczywistym katalogu, byłoby to szybsze.

Przetestujmy to, usuwając kolekcję portów OpenBSD, którą wypisałem z CVS i zamontowałem na NFS:

Na serwerze NFS:

$ cd /export/shared/ports

$ du -hs .
2.6G    .

$ find . | wc -l
  179688

$ time rm -rf /export/shared/ports/*
0m20.87s real     0m00.12s user     0m04.62s system

Na kliencie (po przywróceniu oryginalnych plików z kopii zapasowej):

$ time rm -rf /usr/ports/*
6m49.73s real     0m01.55s user     1m08.96s system
Kusalananda
źródło