Mieux vaut utiliser local en cours d'exécution rm -rf au lieu de sur nfs?

Cela ferait-il une grande différence dans le temps de se connecter sur la machine qui a le répertoire avant de faire un rm -rfsur le répertoire, ou simplement rm -rfle répertoire sur NFS?

Bien sûr, le ssh est le meilleur.

Nfs utilise un protocole réseau complexe avec divers appels de procédure à distance et temps d'attente de synchronisation des données. Dans le cas de ssh, ceux-ci ne s'appliquent pas.

De plus, il existe de nombreuses serrures. La suppression de fichiers dans nfs fonctionne de cette façon:

1. votre rmcommande donne le unlink()syscall
2. le pilote nfs le convertit en une requête sunrpc, l'envoie au serveur nfs
3. le serveur nfs reconvertit cette demande sunrpc en unlink()appel
4. exécute cet unlink()appel du côté distant
5. après avoir réussi, rend au client l'équivalent du message de réponse rpc "ok, c'est fait" au client
6. le pilote du noyau côté client le reconvertit en code de sortie 0 de l' unlink()appel de votre originalrm
7. rm itère dans le fichier suivant, goto 1

Maintenant, la chose importante est: entre 2-7, rmdoit attendre. Il pourrait envoyer le prochain unlink()appel de manière asynchrone, mais il s'agit d'un outil monothread, non orienté événement. Même si c'était le cas, cela nécessiterait toujours des drapeaux de montage nfs difficiles. Jusqu'à ce qu'il n'obtienne pas le résultat, il attend.

Nfs - et tout système de fichiers réseau - est toujours beaucoup plus lent.

Dans de nombreux cas, vous pouvez effectuer des suppressions récursives à vitesse quasi infinie avec une astuce:

1. Déplacez d'abord le répertoire vers un nom différent ( mv -vf oldfilms oldfilms-)
2. Supprimer en arrière-plan ( rm -rf oldfilms- &)

De nombreux aspects (mais pas tous), cette suppression de répertoire semblera avoir été effectuée en un temps pratiquement nul.

Extension: Comme @ el.pascado le mentionne dans son excellent commentaire, en fait 2-7 doit exécuter 3x pour tous les fichiers:

• pour déterminer s'il s'agit d'un fichier ou d'un répertoire (avec un lstat()syscall),
• puis faites en conséquence. Dans le cas des fichiers ordinaires unlink(), dans le cas des répertoires opendir(), la suppression récursive de tous les fichiers / répertoires, puis closedir()enfin rmdir().
• enfin, passez à l'entrée de répertoire suivante avec un readdir()appel.

Cela nécessite 3 commandes nfs RPC pour les fichiers et 3 supplémentaires pour les répertoires.

Oui. Eh bien, peut-être. Ça dépend. Pour un petit nombre de fichiers et de répertoires, cela ne ferait pas beaucoup de différence.

L'opération de fichiers en bloc sur un répertoire monté NFS est lente. Si vous avez la possibilité de vous connecter au serveur NFS lui-même et de le faire sur le répertoire réel, ce serait plus rapide.

Testons-le en supprimant la collection de ports OpenBSD que j'ai extraite de CVS et montée sur NFS:

Sur le serveur 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

Sur le client (après avoir restauré les fichiers d'origine à partir de la sauvegarde):

$ time rm -rf /usr/ports/*
6m49.73s real     0m01.55s user     1m08.96s system