La suppression de fichiers prend trop de temps

Version courte : rm -rf mydiravec mydir(récursive) contenant des fichiers de 2,5 millions, prend environ 12 heures sur une machine la plupart du temps de repos.

Plus d'informations : La plupart des fichiers supprimés sont des liens durs vers des fichiers dans d'autres répertoires (le répertoire supprimé est en fait la plus ancienne sauvegarde effectuée par rsnapshot; la rmcommande est en fait fournie par rsnapshot). Il s'agit donc principalement d'entrées de répertoire supprimées - le contenu du fichier lui-même n'est pas beaucoup; c'est de l'ordre de quelques dizaines de Go.

Je suis loin d'être certain que btrfsc'est le coupable. Je me souviens que la sauvegarde était également très lente avant de commencer à utiliser btrfs, mais je ne suis pas certain que la lenteur était dans la suppression.

La machine est un Intel Core i5 2,67 GHz avec 4 Go de RAM. Il a deux disques SATA: l'un a le système d'exploitation et d'autres éléments, et le disque de sauvegarde est de 1 To WDC WD1002FAEX-00Z3A0. La carte mère est un Asus P7P55D.

Edit : La machine est un Debian Wheezy avec Linux 3.16.3-2~bpo70+1. Voici comment le système de fichiers est monté:

root@thames:~# mount|grep rsnapshot
/dev/sdb1 on /var/backups/rsnapshot type btrfs (rw,relatime,compress=zlib,space_cache)

Edit : l'utilisation rsync -a --delete /some/empty/dir mydirprend environ 6 heures. Une amélioration significative par rapport à rm -rf, mais toujours trop je pense. ( Explication de pourquoi rsyncest plus rapide querm : "[M] ost les systèmes de fichiers stockent leurs structures de répertoires dans un format btree, l'ordre [dans] lequel vous supprimez les fichiers est ... important. Il faut éviter de rééquilibrer le btree lorsque vous effectuez la déconnexion .... rsync -a --delete... fait les suppressions dans l'ordre ")

Edit : j'ai attaché un autre disque qui avait 2,2 millions de fichiers (récursivement) dans un répertoire, mais sur XFS. Voici quelques résultats comparatifs:

                  On the XFS disk      On the BTRFS disk
Cached reads[1]       10 GB/s               10 GB/s
Buffered reads[1]     80 MB/s              115 MB/s
Walk tree[2]         11 minutes            43 minutes
rm -rf mydir[3]       7 minutes            12 hours

[1] Avec hdparm -T /dev/sdXet hdparm -t /dev/sdX.
[2] Temps nécessaire à l'exécution find mydir -print|wc -limmédiatement après le démarrage.
[3] Sur le disque XFS, c'était peu de temps après avoir parcouru l'arbre avec find. Sur le disque BTRFS, c'est l'ancienne mesure (et je ne pense pas que c'était avec l'arborescence mise en cache).

Cela semble être un problème avec btrfs.

Eh bien, c'est toujours un problème Btrfs, c'est bien connu que la suppression de nombreux petits fichiers prend assez de temps par rapport aux autres systèmes de fichiers.

Si vous ne l'aimez pas, vous pouvez soit attendre que l'amont l'ait corrigé, soit passer à un autre système de fichiers qui le fait mieux.

Votre principale erreur est cependant d'utiliser un ancien noyau (3.16, oui, il était déjà ancien lorsque vous avez posté) avec btrfs. Btrfs est un système de fichiers qui est toujours en développement, vous devez donc toujours rester avec la dernière et la meilleure version du noyau pour entrer en contact avec les améliorations. Si votre distribution ne fait pas de rétroportages, vous pouvez le faire vous-même ou vous êtes foutu.

Btrfs a obtenu de nombreuses améliorations de performances dans la version 3.19 du noyau - c'est la version minimale que vous devez utiliser en production, votre version 3.16 du noyau suce clairement sans rétroportages.

Gardez également à l'esprit que, selon Chris Mason, il considère que Btrfs est stable, mais pas encore prêt pour la production.

Je suis un peu en retard à cette fête, mais voici une astuce pour supprimer très rapidement des arbres btrfs extrêmement volumineux:

1. Créez un sous-volume factice sur le même système de fichiers btrfs.
2. Déplacez le répertoire de niveau supérieur que vous souhaitez supprimer dans ledit sous-volume - cette opération devrait être très rapide si vous le faites sur le même système de fichiers btrfs, même entre les sous-volumes.
3. Détruisez le sous-volume.

Le noyau va commencer à récupérer de l'espace en arrière-plan, vous n'aurez donc pas l'espace disponible tout de suite, mais le processus devrait être beaucoup plus rapide que de faire n'importe quelle sorte de suppression d'espace utilisateur.

Vous pouvez renommer le répertoire, puis supprimer le répertoire renommé dans un processus d'arrière-plan. Cela ne va pas accélérer l'opération de suppression. Cependant, cela permettrait au programme de continuer vers l'avant avec un répertoire vide pendant que l'opération de suppression se produit sur le côté.

Je ne sais pas si cela va fonctionner dans votre cas d'utilisation. Cela dépend si le programme ne peut pas continuer jusqu'à ce que le disque soit inactif (c'est-à-dire qu'il va faire des opérations de disque lourdes). Cela dépend si le programme va remplir le disque avec beaucoup de données.