Pourquoi rm est-il lent sur un lecteur de stockage externe (connecté par USB, type fuseblk) avec 50 Go de fichiers?

J'ai essayé d'utiliser rsnapshot pour faire des sauvegardes, mais je le trouve inutilisable. Bien qu'il soit capable de différencier un répertoire (50 Go) et de le dupliquer (relier en dur tous les fichiers) en quelques minutes, et je peux cp le répertoire entier en environ une demi-heure, il faut plus d'une heure pour le supprimer. Même en utilisant directement rm -rfv, je trouve qu'il peut prendre jusqu'à une demi-seconde pour rm un seul fichier, tandis que les commandes cpet se linkterminent instantanément.

Pourquoi rm est-il si lent? Existe-t-il un moyen plus rapide de supprimer récursivement les liens physiques? Cela n'a pas de sens pour moi que la copie d'un fichier devrait prendre moins de temps que sa suppression.

Le système de fichiers sur lequel je travaille est un lecteur de stockage externe, connecté via USB et de type fuseblk (ce qui, je pense, signifie que c'est ntfs). Mon ordinateur exécute Ubuntu Linux.

Sortie par le haut:

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

En fin de compte, peu importe ce que vous faites, vous devez rmexécuter unlinktous les fichiers que vous souhaitez supprimer (même si vous appelez rm -rle répertoire parent). S'il y a beaucoup de fichiers à supprimer, cela peut prendre du temps.

Il existe deux processus particulièrement longs lorsque vous exécutez rm -r:

1. readdir, suivi par,
2. un certain nombre d'appels vers unlink.

Trouver tous les fichiers, puis parcourir chaque fichier pour le supprimer, peut prendre beaucoup de temps.

Si vous trouvez cette "inutilisable" car elle rend le répertoire inutilisable pendant un certain temps, pensez à déplacer le répertoire parent avant de le supprimer. Cela libérera ce nom pour que le programme puisse l'utiliser à nouveau, sans que le temps ne soit trop gênant.

En supposant que le système de fichiers est vraiment NTFS (cela ne ressort pas clairement de votre question), NTFS est généralement assez lent pour supprimer de larges pans de fichiers. Vous pourriez envisager d'utiliser un système de fichiers plus adapté à vos besoins (les systèmes de fichiers ext les plus récents ont de très bonnes performances de suppression, si vous n'avez pas d'autres besoins particuliers). FUSE lui-même n'est pas non plus particulièrement rapide, en général. Vous pourriez envisager de voir si vous pouvez le faire d'une manière qui n'utilise pas FUSE.

Pourquoi rm est-il si lent? Je n'ai aucune idée. Mais je connais un moyen plus rapide:

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

Mise à jour: Cette réponse sur Serverfault a quelques explications. Il semble que rsync supprime les fichiers dans un ordre particulier, ce qui fait que l'arborescence du système de fichiers reste équilibrée et n'a jamais besoin d'être rééquilibrée. rm supprimera simplement les fichiers et provoquera beaucoup de rééquilibrage à mesure qu'ils sont supprimés. Il y a quelques informations sur le rééquilibrage ici .

Eh bien, j'ai déjà eu un problème similaire avec le vôtre. J'ai trouvé que votre "wa" est élevé, vous pouvez utiliser

iostat -x 1

pour vérifier si votre utilisation du disque est élevée, si c'est le cas, cela signifie que votre disque est assez occupé. Vérifiez que certains autres processus écrivent en continu sur le disque.

Pour plus de simplicité, utilisez

vmstat 1

pour vérifier si b est élevé ou r < b . Cela indique quelque chose de mal. Dans votre situation, je pense que le disque io est la raison d'origine.