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
la source
fuseblkne signifie pas que le lecteur est NTFS, cela signifie simplement qu'il est monté en tant que périphérique bloc FUSE. Cela pourrait être presque n'importe quoi.Réponses:
En fin de compte, peu importe ce que vous faites, vous devez
rmexécuterunlinktous les fichiers que vous souhaitez supprimer (même si vous appelezrm -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:readdir, suivi par,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.
la source
Pourquoi rm est-il si lent? Je n'ai aucune idée. Mais je connais un moyen plus rapide:
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 .
la source
rm -rf?rsyncdoit encore contenirunlink()tous les fichierstest/, et c'est probablement ce qui prend le temps.unlink(2)sur le répertoire (et se souvenir d'en fairefsckplus tard) ...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
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
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.
la source