rm sur un répertoire contenant des millions de fichiers

TLDR : utiliser rsync -a --delete emptyfolder/ x .

Cette question a été vue 50 000 fois et a donné lieu à de nombreuses réponses, mais personne ne semble avoir analysé les différentes réponses. Il y a un lien vers un benchmark externe, mais celui-ci date de plus de 7 ans et n'a pas examiné le programme fourni dans cette réponse : https://serverfault.com/a/328305/565293

La difficulté réside en partie dans le fait que le temps nécessaire pour supprimer un fichier dépend fortement des disques utilisés et du système de fichiers. Dans mon cas, j'ai testé les deux avec un SSD grand public exécutant BTRFS sur Arch Linux (mis à jour en 2020-03), mais j'ai obtenu le même classement des résultats sur une distribution (Ubuntu 18.04), un système de fichiers (ZFS) et un type de disque (HDD dans une configuration RAID10) différents.

La configuration du test était identique pour chaque essai :

# setup
mkdir test && cd test && mkdir empty
# create 800000 files in a folder called x
mkdir x && cd x
seq 800000 | xargs touch
cd ..

Résultats des tests :

rm -rf x : 30.43s

find x/ -type f -delete : 29.79

*`perl -e 'for(<>){((stat)[9]<(unlink))}'`** : 37.97s

rsync -a --delete empty/ x : 25.11s

(Le programme suivant est celui de cette réponse mais modifié pour ne rien imprimer ou attendre avant de supprimer les fichiers).

./dentls --delete x : 29.74

El rsync s'est avéré être le vainqueur à chaque fois que j'ai répété le test, bien que par une marge assez faible. Le site perl était plus lente que toute autre option sur mes systèmes.

De manière quelque peu choquante, le programme de la première réponse à cette question s'est avéré ne pas être plus rapide sur mes systèmes qu'un simple rm -rf . Essayons de comprendre pourquoi.

Tout d'abord, la réponse prétend que le problème est que rm utilise readdir avec une taille de buffer fixe de 32Kb avec getdents . Cela ne s'est pas avéré être le cas sur mon système Ubuntu 18.04, qui utilisait un buffer quatre fois plus grand. Sur le système Arch Linux, il utilisait getdents64 .

De plus, la réponse fournit de manière trompeuse des statistiques donnant sa vitesse à liste les fichiers d'un grand répertoire, mais sans les supprimer (ce qui est le sujet de la question). Il compare dentls a ls -u1 mais un simple strace révèle que getdents es no la raison pour laquelle ls -u1 est lent, du moins pas sur mon système (Ubuntu 18.04 avec 1000000 fichiers dans un répertoire) :

strace -c ls -u1 x >/dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 94.00    7.177356           7   1000000           lstat
  5.96    0.454913        1857       245           getdents
[snip]

Ce site ls fait un million d'appels à lstat ce qui ralentit considérablement le programme. Le site getdents les appels ne font que 0,455 seconde. Combien de temps durent les getdents les appels sont pris en charge dentls sur le même dossier ?

strace -c ./dentls x >/dev/null
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 99.91    0.489895       40825        12           getdents
[snip]

C'est vrai ! Même si dentls ne fait que 12 appels au lieu de 245, il faut en fait au système plus longtemps pour exécuter ces appels. L'explication donnée dans cette réponse est donc incorrecte, du moins pour les deux systèmes sur lesquels j'ai pu la tester.

Il en va de même pour rm y dentls --delete . Considérant que rm prend 0,42s en appelant getdents , dentls prend 0,53s. Sur soit Dans ce cas, la grande majorité du temps est passée à appeler unlink !

En résumé, ne vous attendez pas à des accélérations massives en cours d'exécution. dentls à moins que votre système ne soit comme celui de l'auteur et qu'il ait beaucoup de frais généraux sur les individus. getdents . Peut-être que les gens de la glibc ont considérablement accéléré le processus depuis que la réponse a été écrite, et qu'il faut maintenant un temps de réponse linéaire pour différentes tailles de tampon. Ou peut-être que le temps de réponse de getdents dépend de l'architecture du système d'une manière qui n'est pas évidente.

Find n'a tout simplement pas fonctionné pour moi, même après avoir modifié les paramètres du fs ext3 comme suggéré par les utilisateurs ci-dessus. Il consomme beaucoup trop de mémoire. Ce script PHP a fait l'affaire - rapide, utilisation insignifiante du CPU, utilisation insignifiante de la mémoire :

<?php 
$dir = '/directory/in/question';
$dh = opendir($dir)) { 
while (($file = readdir($dh)) !== false) { 
    unlink($dir . '/' . $file); 
} 
closedir($dh); 
?>

J'ai posté un rapport de bogue concernant ce problème avec find : http://savannah.gnu.org/bugs/?31961

Assurez-vous de le faire :

mount -o remount,rw,noatime,nodiratime /mountpoint

ce qui devrait aussi accélérer un peu les choses.

J'ai récemment été confronté à un problème similaire et j'ai été incapable d'obtenir des ring0's. data=writeback suggestion de fonctionner (peut-être en raison du fait que les fichiers sont sur ma partition principale). En cherchant des solutions de contournement, je suis tombé sur ceci :

tune2fs -O ^has_journal <device>

Cela désactivera complètement la journalisation, quelle que soit l'option choisie. data option donnée à mount . J'ai combiné cela avec noatime et le volume avait dir_index et ça semblait fonctionner plutôt bien. La suppression s'est terminée sans que j'aie besoin de la tuer, mon système est resté réactif et il est maintenant de nouveau opérationnel (avec la journalisation réactivée) sans aucun problème.

La commande ls est très lente. Essayez :

find /dir_to_delete ! -iname "*.png" -type f -delete