Comment puis-je supprimer rapidement un dossier contenant de nombreux sous-dossiers?

15

J'ai un dossier avec 266778 sous-dossiers. Comment puis-je le supprimer?

j'ai essayé

cd ~/.local/share/Trash/
sudo rm -rf *

mais cela prend beaucoup de temps. Après 1 minute 25 secondes en temps réel et 0,072 secondes de temps utilisateur, il n'a supprimé que 2500 dossiers. De cette façon, il faudra plus de deux heures pour supprimer ce dossier.

Existe-t-il un moyen plus rapide de supprimer ce dossier? Pourquoi y a-t-il une si grande différence entre le temps utilisateur et le temps réel?

real    1m25.474s
user    0m0.072s
sys     0m28.142s

J'utilise Linux 2.6.32 (Ubuntu 10.04.4 LTS).

filesystems rm

— Martin Thoma
source

Je viens de googler ce problème et il semble que certaines personnes ont découvert que rsync peut être utilisé comme un outil de «suppression de plusieurs fichiers» assez efficacement. Que ce soit vraiment plus rapide reste à vous d'évaluer.

— Johan

2

Pour ce que ça vaut: les performances lors de la suppression de nombreux dossiers / fichiers dépendent fortement du système de fichiers. D'après mon expérience, la différence lors de la suppression de millions de petits fichiers sur ext3 (lent) par rapport à XFS (rapide) peut être de plusieurs heures.

— pdo

Si vous avez souvent ce cas et que vous pouvez planifier à l'avance, en utilisant un système de fichiers comme btrfs et en utilisant un sous-volume, vous pouvez accélérer les choses rapidement en vidant simplement ce sous-volume.

— PlasmaHH

Voici où vous pouvez trouver la réponse. Le perl est le plus rapide. unix.stackexchange.com/questions/37329/…

— SDsolar

17

Si votre version de "find" implémente la sous-commande -delete, vous pouvez essayer

find directory -delete

Dans ce cas:

find ~/.local/share/Trash/ -delete

Certaines commandes, comme rm, effectuent la plupart de leur travail dans le noyau. Dans les routines du système de fichiers, pour être exact. Le temps passé à effectuer des appels système est pris en compte de cette manière. Ainsi, bien que votre commande "rm" s'exécute pendant une longue période, elle ne fait pas beaucoup de travail dans l'espace utilisateur - les appels système effectuent la majeure partie du travail.

— Johan
source

+1; bien que cela supprime également le répertoire parent et je soupçonne que l'OP ne voulait que supprimer le contenu du dossier Corbeille et non le dossier lui

— don_crissti

1

@don_crissti: bonne remarque. si l'OP ne voulait supprimer que les sous-répertoires sous ~ / .local / share / Trash (et non les fichiers au 1er niveau), alors: find ~/.local/share/Trash/*/ -delete (bien sûr, cela supprimera également les fichiers (et les répertoires) dans l'un de ces Corbeille / * / subdirs ainsi)

— Olivier Dulac

2

+1 pour avoir expliqué le comportement étrange detime

— Martin Thoma

3

Est-ce find directory -deletevraiment plus rapide que rm -rf directory? Après tout, ils effectuent le même travail et il n'y a pas deux façons de le faire.

— Gilles 'SO- arrête d'être méchant'

1

@Johan find est vraiment rapide. Avez-vous déjà eu la chance de découvrir la raison?

— Harshdeep

20

Cela dépend de votre définition du jeûne . Les réponses déjà ici donnent une bonne solution pour supprimer réellement les répertoires du système de fichiers, mais si ce dont vous avez vraiment besoin est de libérer le nom du répertoire le plus rapidement possible, un changement de nom sur le même système de fichiers est instantané:

{ mv directory directory.gone && rm -rf directory.gone; } &

Techniquement, c'est de la triche puisque je n'ai pas accéléré la suppression, mais pratiquement c'est très utile: j'utilise cette astuce tout le temps, donc je n'ai pas à attendre des opérations de suppression lentes.

— kojiro
source

Génial. Quel est votre cas d'utilisation pour faire cela tout le temps? Si vous le faites souvent, n'y a-t-il pas un danger que vous retardiez, obteniez plusieurs répertoires et échouiez? Je suppose que vous utilisez un suffixe comme '$$' ou '% (date ...)'

— smci

1

Si j'avais besoin de cela, je pourrais probablement utiliser mktemp avec des arguments qui garantissent qu'il reste sur le même système de fichiers. Mais je ne peux pas dire que j'ai un exemple spécifique en ce moment.

— kojiro

kojiro ouais merci, mktempc'est ce que j'essayais de retenir ...

— smci

1

rm -rf directoryou rm -rf *bien sûr, c'est la méthode la plus rapide à moins que votre rmimplémentation locale ne soit interrompue.

L'utilisation findne donne aucun avantage.

Que ce soit rapide ou lent dépend principalement du système de fichiers et de l'implémentation du système d'exploitation. La question semble donc inappropriée.

UFS et ZFS sur Solaris sont connus pour être très rapides avec ce type de tâche, car les deux implémentations du système de fichiers incluent un code de suppression d'arrière-plan retardé qui provoque le retour rapide des appels unlink()et rmdir()même lorsque l'objet associé prendra plus de temps au total.

Avec la suppression d'arrière-plan retardée dans le noyau, les mises à jour du répertoire peuvent également être effectuées rapidement et cela aide à accélérer l'ensemble de l'opération.

— schily
source

Bien que l'on puisse être pardonné de penser cela, ce n'est en fait pas vrai, comme cette réponse le décrit.

— Hitechcomputergeek

0

Ce n'est qu'une réponse partielle, mettant en lumière les trois valeurs renvoyées par la commande; cité dans la time(1)page de manuel :

(i) le temps réel écoulé entre l'invocation et la fin, (ii) le temps CPU de l'utilisateur (la somme des valeurs tms_utimeet tms_cutimedans un struct tmstel que retourné par times(2)), et (iii) le temps CPU du système (la somme des valeurs tms_stimeet tms_cstimedans un struct tmstel que renvoyé par times(2)). "

— Schaiba
source