Question rm sur un répertoire avec des millions de fichiers


Arrière-plan: serveur physique, âgé d'environ deux ans, disques SATA à 7 200 tr / min connectés à une carte RAID 3Ware, ext3 FS monté avec noatime et data = commandé, pas sous une charge folle, noyau 2.6.18-92.1.22.el5, temps de disponibilité 545 jours . Directory ne contient aucun sous-répertoire, mais des millions de petits fichiers (~ 100 octets), avec des fichiers plus volumineux (quelques Ko).

Nous avons un serveur qui est devenu un peu coucou au cours des derniers mois, mais nous ne l’avons remarqué que l’autre jour quand il a commencé à être incapable d’écrire dans un répertoire car il contenait trop de fichiers. Plus précisément, il a commencé à générer cette erreur dans / var / log / messages:

ext3_dx_add_entry: Directory index full!

Le disque en question a beaucoup d’inodes restants:

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda3            60719104 3465660 57253444    6% /

Donc, je suppose que cela signifie que nous atteignons la limite du nombre d'entrées pouvant être dans le fichier de répertoire lui-même. Aucune idée du nombre de fichiers, mais il ne peut pas y avoir plus de trois millions, comme vous pouvez le constater. Ce n'est pas bien, remarquez! Mais c’est la première partie de ma question: quelle est exactement cette limite supérieure? Est-ce accordable? Avant de me faire engueuler - je veux l'accorder vers le bas; cet énorme répertoire a causé toutes sortes de problèmes.

Quoi qu'il en soit, nous avons repéré le problème dans le code qui générait tous ces fichiers, et nous l'avons corrigé. Maintenant, je suis coincé avec la suppression du répertoire.

Quelques options ici:

  1. rm -rf (dir)

J'ai essayé ceci en premier. J'ai abandonné et je l'ai tué après une journée et demie sans impact perceptible.

  • unlink (2) sur le répertoire: Cela mérite certainement d'être pris en compte, mais la question est de savoir s'il serait plus rapide de supprimer les fichiers du répertoire via fsck que de supprimer via unlink (2). C'est-à-dire que, d'une manière ou d'une autre, je dois marquer ces inodes comme inutilisés. Bien entendu, cela suppose que je puisse dire à fsck de ne pas supprimer les entrées dans les fichiers de / lost + found; sinon, je viens de déplacer mon problème. En plus de toutes les autres préoccupations, après avoir lu un peu plus à ce sujet, il s'avère que je devrais probablement appeler des fonctions FS internes, car aucune des variantes unlink (2) que je peux trouver ne me permettrait de supprimer allègrement. un répertoire avec des entrées. Caca.
  • while [ true ]; do ls -Uf | head -n 10000 | xargs rm -f 2>/dev/null; done )
  • C'est en fait la version abrégée; le vrai que je suis en train d’exécuter, qui ajoute simplement des rapports de progression et un arrêt net lorsque nous sommes à court de fichiers à supprimer, est le suivant:

    exportation i = 0;
    time (while [true]; do
      ls -Uf | tête -n 3 | grep -qF '.png' || Pause;
      ls -Uf | tête -n 10000 | xargs rm -f 2> / dev / null;
      exportation i = $ (($ i + 10000));
      echo "$ i ...";
    terminé )

    Cela semble fonctionner plutôt bien. Au moment où j'écris ces lignes, il a supprimé 260 000 fichiers au cours des trente dernières minutes.


    97
    2017-09-22 23:57


    origine


    rm (GNU coreutils) 8.4 a cette option: "-v, --verbose explique ce qui se fait". Il affichera tous les fichiers en cours de suppression. - Cristian Ciupitu
    En fait, ce serait une façon élégante de faire une barre de progression: puisque chaque fichier aurait trente-sept caractères (36 + a '\ n'), je pourrais facilement écrire un analyseur pour cela, et comme printf () est cheap et que la commande rm a déjà le nom du fichier chargé, il n’ya aucune pénalité de performances particulière. On dirait que je ne suis pas partant pour faire tout le tralala, car je ne pourrais jamais obtenir de "rm" quoi que ce soit de la sorte. Mais cela pourrait très bien fonctionner comme une barre de progression sur 10 000; peut-être un "." pour chaque cent fichiers? - BMDan
    rm -rfv | pv -l >/dev/null. pv devrait être disponible dans le EPEL dépôt. - Cristian Ciupitu
    pv est incroyablement génial. Je laisse une traînée d'installations PV dans mon sillage. - BMDan
    J'ai eu exactement ce même problème récemment. Je vous remercie! - richo


    Réponses:


    le data=writeback L’option de montage mérite d’être essayée afin d’empêcher la journalisation du système de fichiers. Cela ne devrait être fait que pendant la période de suppression. Cependant, le serveur est en train d'être arrêté ou redémarré pendant l'opération de suppression.

    Selon cette page,

    Certaines applications montrent une amélioration très significative de la vitesse d'utilisation. Par exemple, des améliorations de la vitesse peuvent être constatées (...) lorsque les applications créent et suppriment de gros volumes de petits fichiers.

    L'option est définie soit dans fstab ou pendant l'opération de montage, en remplaçant data=ordered avec data=writeback. Le système de fichiers contenant les fichiers à supprimer doit être remonté.


    30
    2017-09-26 05:49



    Il pourrait aussi augmenter le temps de la commit  option: "Cette valeur par défaut (ou toute valeur basse) va nuire aux performances, mais elle est bonne pour la sécurité des données. Le réglage sur 0 aura le même effet que de le laisser sur la valeur par défaut (5 secondes). Le réglage sur des valeurs très grandes améliorer les performances". - Cristian Ciupitu
    Writeback semble stellaire, sauf la documentation que je cherchais (gentoo.org/doc/fr/articles/l-afig-p8.xml#doc_chap4) mentionne explicitement que les métadonnées sont toujours journalisées, ce qui, je suppose, inclut toutes les données que je modifie (je ne modifie certainement aucune donnée des fichiers eux-mêmes). Est-ce que ma compréhension de l'option est incorrecte? - BMDan
    Enfin, pour information, ce lien ne mentionne pas le fait que data = writeback peut être un énorme trou de sécurité, car les données pointées par une entrée donnée peuvent ne pas contenir les données écrites par l'application, ce qui signifie qu'un crash pourrait en résulter dans les anciennes données potentiellement sensibles / privées exposées. Ce n’est pas un problème ici, car nous l’allumons seulement temporairement, mais je voulais alerter tout le monde de cette mise en garde au cas où vous-même ou d’autres personnes qui rencontriez cette suggestion n’étiez pas au courant. - BMDan
    commet: c'est assez lisse! Merci pour le pointeur. - BMDan
    data=writeback met toujours les métadonnées en revue avant de les écrire dans le système de fichiers principal. Si je comprends bien, cela ne fait tout simplement pas appliquer l'ordre entre des tâches telles que l'écriture d'une carte d'étendue et l'écriture de données dans ces domaines. Peut-être y at-il d’autres contraintes d’ordre qui s’atténuent si vous en tirez un avantage. Bien entendu, un montage sans journal pourrait être encore plus performant. (Cela pourrait laisser les modifications de métadonnées se produire dans la RAM, sans rien avoir besoin d’être sur le disque avant la fin de l’opération de dissociation) - Peter Cordes


    Une des principales causes de ce problème est la performance ext3 avec des millions de fichiers, mais la cause première de ce problème est différente.

    Lorsqu'un répertoire doit être répertorié, readdir () est appelé sur le répertoire, ce qui génère une liste de fichiers. readdir est un appel posix, mais le véritable appel système Linux utilisé ici s'appelle 'getdents'. Getdents liste les entrées du répertoire en remplissant un tampon avec des entrées.

    Le problème tient principalement au fait que readdir () utilise une taille de tampon fixe de 32 Ko pour extraire des fichiers. Lorsqu'un répertoire devient de plus en plus grand (la taille augmente à mesure que des fichiers sont ajoutés), ext3 lit de plus en plus lentement pour extraire des entrées et la taille de mémoire tampon supplémentaire de 32 Ko de readdir est suffisante pour inclure une fraction des entrées du répertoire. Readdir est ainsi mis en boucle, invoquant ainsi l'appel système coûteux, encore et encore.

    Par exemple, sur un répertoire de test que j'ai créé et contenant plus de 2,6 millions de fichiers, l'exécution de "ls -1 | wc-l" affiche une grande sortie strace de nombreux appels système getdent.

    $ strace ls -1 | wc -l
    brk(0x4949000)                          = 0x4949000
    getdents(3, /* 1025 entries */, 32768)  = 32752
    getdents(3, /* 1024 entries */, 32768)  = 32752
    getdents(3, /* 1025 entries */, 32768)  = 32760
    getdents(3, /* 1025 entries */, 32768)  = 32768
    brk(0)                                  = 0x4949000
    brk(0x496a000)                          = 0x496a000
    getdents(3, /* 1024 entries */, 32768)  = 32752
    getdents(3, /* 1026 entries */, 32768)  = 32760
    ...
    

    De plus, le temps passé dans ce répertoire était significatif.

    $ time ls -1 | wc -l
    2616044
    
    real    0m20.609s
    user    0m16.241s
    sys 0m3.639s
    

    La méthode pour rendre ce processus plus efficace consiste à appeler getdents manuellement avec un tampon beaucoup plus volumineux. Cela améliore considérablement les performances.

    Maintenant, vous n’êtes pas censé appeler vous-même manuellement getdents, il n’existe donc pas d’interface permettant de l’utiliser normalement (consultez la page de manuel relative à getdents pour voir!). pouvez appelez-le manuellement et rendez votre moyen d’appel d’appel système plus efficace.

    Cela réduit considérablement le temps nécessaire pour récupérer ces fichiers. J'ai écrit un programme qui fait ça.

    /* I can be compiled with the command "gcc -o dentls dentls.c" */
    
    #define _GNU_SOURCE
    
    #include <dirent.h>     /* Defines DT_* constants */
    #include <err.h>
    #include <fcntl.h>
    #include <getopt.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <sys/stat.h>
    #include <sys/syscall.h>
    #include <sys/types.h>
    #include <unistd.h>
    
    struct linux_dirent {
            long           d_ino;
            off_t          d_off;
            unsigned short d_reclen;
            char           d_name[256];
            char           d_type;
    };
    
    static int delete = 0;
    char *path = NULL;
    
    static void parse_config(
            int argc,
            char **argv)
    {
        int option_idx = 0;
        static struct option loptions[] = {
          { "delete", no_argument, &delete, 1 },
          { "help", no_argument, NULL, 'h' },
          { 0, 0, 0, 0 }
        };
    
        while (1) {
            int c = getopt_long(argc, argv, "h", loptions, &option_idx);
            if (c < 0)
                break;
    
            switch(c) {
              case 0: {
                  break;
              }
    
              case 'h': {
                  printf("Usage: %s [--delete] DIRECTORY\n"
                         "List/Delete files in DIRECTORY.\n"
                         "Example %s --delete /var/spool/postfix/deferred\n",
                         argv[0], argv[0]);
                  exit(0);                      
                  break;
              }
    
              default:
              break;
            }
        }
    
        if (optind >= argc)
          errx(EXIT_FAILURE, "Must supply a valid directory\n");
    
        path = argv[optind];
    }
    
    int main(
        int argc,
        char** argv)
    {
    
        parse_config(argc, argv);
    
        int totalfiles = 0;
        int dirfd = -1;
        int offset = 0;
        int bufcount = 0;
        void *buffer = NULL;
        char *d_type;
        struct linux_dirent *dent = NULL;
        struct stat dstat;
    
        /* Standard sanity checking stuff */
        if (access(path, R_OK) < 0) 
            err(EXIT_FAILURE, "Could not access directory");
    
        if (lstat(path, &dstat) < 0) 
            err(EXIT_FAILURE, "Unable to lstat path");
    
        if (!S_ISDIR(dstat.st_mode))
            errx(EXIT_FAILURE, "The path %s is not a directory.\n", path);
    
        /* Allocate a buffer of equal size to the directory to store dents */
        if ((buffer = calloc(dstat.st_size*3, 1)) == NULL)
            err(EXIT_FAILURE, "Buffer allocation failure");
    
        /* Open the directory */
        if ((dirfd = open(path, O_RDONLY)) < 0) 
            err(EXIT_FAILURE, "Open error");
    
        /* Switch directories */
        fchdir(dirfd);
    
        if (delete) {
            printf("Deleting files in ");
            for (int i=5; i > 0; i--) {
                printf("%u. . . ", i);
                fflush(stdout);
                sleep(1);
            }
            printf("\n");
        }
    
        while (bufcount = syscall(SYS_getdents, dirfd, buffer, dstat.st_size*3)) {
            offset = 0;
            dent = buffer;
            while (offset < bufcount) {
                /* Don't print thisdir and parent dir */
                if (!((strcmp(".",dent->d_name) == 0) || (strcmp("..",dent->d_name) == 0))) {
                    d_type = (char *)dent + dent->d_reclen-1;
                    /* Only print files */
                    if (*d_type == DT_REG) {
                        printf ("%s\n", dent->d_name);
                        if (delete) {
                            if (unlink(dent->d_name) < 0)
                                warn("Cannot delete file \"%s\"", dent->d_name);
                        }
                        totalfiles++;
                    }
                }
                offset += dent->d_reclen;
                dent = buffer + offset;
            }
        }
        fprintf(stderr, "Total files: %d\n", totalfiles);
        close(dirfd);
        free(buffer);
    
        exit(0);
    }
    

    Bien que cela ne combat pas le problème fondamental sous-jacent (beaucoup de fichiers, dans un système de fichiers qui fonctionne mal). Cela risque d'être beaucoup, beaucoup plus rapide que la plupart des alternatives affichées.

    En prévision, il convient de supprimer le répertoire affecté et de le refaire ensuite. La taille des répertoires n’augmente jamais et peut rester médiocre, même avec quelques fichiers, à cause de la taille du répertoire.

    Modifier: J'ai nettoyé cela un peu. Ajout d'une option pour vous permettre de supprimer sur la ligne de commande au moment de l'exécution et suppression d'un tas de trucs de promenade dans les arbres qui, honnêtement, rétrospectivement, était au mieux discutable. Aussi a été montré pour produire une corruption de mémoire.

    Vous pouvez maintenant faire dentls --delete /my/path

    Nouveaux résultats Basé sur un répertoire de 1,82 million de fichiers.

    ## Ideal ls Uncached
    $ time ls -u1 data >/dev/null
    
    real    0m44.948s
    user    0m1.737s
    sys 0m22.000s
    
    ## Ideal ls Cached
    $ time ls -u1 data >/dev/null
    
    real    0m46.012s
    user    0m1.746s
    sys 0m21.805s
    
    
    ### dentls uncached
    $ time ./dentls data >/dev/null
    Total files: 1819292
    
    real    0m1.608s
    user    0m0.059s
    sys 0m0.791s
    
    ## dentls cached
    $ time ./dentls data >/dev/null
    Total files: 1819292
    
    real    0m0.771s
    user    0m0.057s
    sys 0m0.711s
    

    Était un peu surpris cela fonctionne toujours si bien!


    73
    2017-11-06 19:06



    Deux préoccupations mineures: une, [256] devrait probablement être [FILENAME_MAX]et deuxièmement, mon Linux (2.6.18 == CentOS 5.x) ne semble pas inclure d’entrée d_type dans dirent (au moins d’après getdents (2)). - BMDan
    Pourriez-vous nous en dire un peu plus sur le rééquilibrage de l'arborescence et sur les raisons pour lesquelles la suppression permet d'éviter de le supprimer? J'ai essayé Google pour cela, malheureusement sans succès. - ovgolovin
    Parce que maintenant, il me semble que si nous supprimons dans l'ordre, nous forçons le rééquilibrage, car nous retirons les feuilles d'un côté et partons de l'autre: en.wikipedia.org/wiki/B-tree#Rebalancing_after_deletion - ovgolovin
    J'espère que je ne vous dérange pas avec ça. Mais j’ai quand même posé une question sur la suppression de fichiers dans l’ordre stackoverflow.com/q/17955459/862380, qui semble ne pas recevoir de réponse qui explique le problème avec l'exemple, ce qui sera compréhensible pour les programmeurs ordinaires. Si vous avez le temps et si vous en avez envie, pourriez-vous vous renseigner? Peut-être que vous pourriez écrire une meilleure explication. - ovgolovin
    C'est un morceau de code incroyable. C’était le seul outil que je pouvais trouver capable de répertorier et de supprimer quelque 11 000 000 (11 millions) de fichiers de session qui s’étaient accumulés dans un répertoire, probablement sur plusieurs années. Le processus Plesk qui était censé les garder sous contrôle à l'aide de find et d'autres astuces dans d'autres réponses ici ne pouvait pas terminer une analyse. Les fichiers ne cessaient donc de s'accumuler. Il s'agit d'un hommage à l'arborescence binaire utilisée par le système de fichiers pour stocker le répertoire. Les sessions ont pu fonctionner. Vous pouvez créer un fichier et le récupérer sans délai. Juste les annonces étaient inutilisables. - Jason


    Serait-il possible de sauvegarder tous les autres fichiers de ce système de fichiers dans un emplacement de stockage temporaire, de reformater la partition, puis de restaurer les fichiers?


    31
    2017-09-23 00:27



    J'aime vraiment cette réponse, en fait. Sur le plan pratique, dans ce cas, non, mais ce n’est pas celui auquel j’aurais pensé. Bravo! - BMDan
    Exactement ce que je pensais aussi. Ceci est une réponse pour la question 3. Idéal si vous me demandez :) - Joshua


    Il n'y a pas de limite de fichier par répertoire dans ext3, mais uniquement la limite d'inode du système de fichiers (je pense cependant qu'il existe une limite quant au nombre de sous-répertoires).

    Vous pouvez toujours avoir des problèmes après la suppression des fichiers.

    Lorsqu'un répertoire contient des millions de fichiers, l'entrée de répertoire elle-même devient très grande. L'entrée du répertoire doit être analysée pour chaque opération de suppression, ce qui prend différentes durées pour chaque fichier, en fonction de l'emplacement de l'entrée. Malheureusement, même après la suppression de tous les fichiers, l'entrée du répertoire conserve sa taille. Par conséquent, les opérations supplémentaires nécessitant l'analyse de l'entrée du répertoire prendront encore beaucoup de temps, même si le répertoire est maintenant vide. Le seul moyen de résoudre ce problème consiste à renommer le répertoire, à en créer un nouveau avec l'ancien nom et à transférer tous les fichiers restants dans le nouveau. Supprimez ensuite celui qui a été renommé.


    11
    2017-09-23 05:45



    En effet, j'ai juste remarqué ce comportement après avoir tout supprimé. Heureusement, nous avions déjà supprimé le répertoire de la "ligne de tir", pour que je puisse le supprimer. - BMDan
    Cela dit, s'il n'y a pas de limite de fichiers par répertoire, pourquoi ai-je obtenu "ext3_dx_add_entry: index du répertoire plein!" quand il y avait encore des inodes disponibles sur cette partition? Il n'y avait pas de sous-répertoires dans ce répertoire. - BMDan
    hmm, j'ai fait un peu plus de recherches et il semble qu'il y ait une limite de blocs qu'un répertoire peut prendre. Le nombre exact de fichiers dépend de quelques facteurs, par exemple la longueur du nom de fichier. Ce gossamer-threads.com/lists/linux/kernel/921942 semble indiquer qu'avec des blocs de 4k, vous devriez pouvoir avoir plus de 8 millions de fichiers dans un répertoire. Étaient-ils des noms de fichiers particulièrement longs? - Alex J. Roberts
    Chaque nom de fichier comportait exactement 36 caractères. - BMDan
    ben ça me manque d'idées :) - Alex J. Roberts


    Je ne l'ai pas évalué, mais ce gars a fait:

    rsync -a --delete ./emptyDirectoty/ ./hugeDirectory/
    

    5
    2018-06-04 11:52





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

    <?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


    4
    2017-12-23 19:54



    Cela m'a sauvé! - jestro


    J'ai récemment fait face à un problème similaire et j'étais incapable d'obtenir des ring0 data=writeback suggestion de travailler (probablement 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, indépendamment de la data option donner à mount. J'ai combiné cela avec noatime et le volume avait dir_index mis, et cela semblait fonctionner assez bien. La suppression s’est en fait terminée sans que je n’aie besoin de la supprimer, mon système est resté réactif et il est maintenant remis en service (avec journalisation réactivée) sans aucun problème.


    3
    2018-04-23 22:29



    J'allais suggérer de le monter en tant qu'ext2 au lieu de ext3, pour éviter de journaliser les opérations de métadonnées. Cela devrait faire la même chose. - Peter Cordes


    Assurez-vous de le faire:

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

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


    3
    2017-09-27 02:03



    Bon appel, mais il est déjà monté noatime, comme je l'ai mentionné dans l'en-tête de la question. Et nodiratime est redondant; voir lwn.net/Articles/245002 . - BMDan
    ppl répète ce mantra "noatime, nodiratime, nodevatime, noreadingdocsatime" - poige


    La commande est très lente. Essayer:

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

    2
    2017-09-23 04:04



    rm -rf a fonctionné pendant un jour et demi et je l'ai finalement tué, sans jamais savoir s'il avait réellement accompli quelque chose. J'avais besoin d'une barre de progression. - BMDan
    Pour que rm soit très lent, "time find. -Delete" sur 30k fichiers: 0m0.357s / 0m0.019s / 0m0.337s real / user / sys. "heure (ls -1U | xargs rm -f)" sur ces mêmes fichiers: 0m0.366s / 0m0.025s / 0m0.340s. Ce qui est fondamentalement un territoire de marge d'erreur. - BMDan
    Tu aurais pu courir strace -r -p <pid of rm> pour attacher au processus rm déjà en cours d'exécution. Ensuite, vous pouvez voir à quelle vitesse unlink les appels système défilent. (-r place le temps écoulé depuis le dernier appel système au début de chaque ligne.) - Peter Cordes


    Est dir_index défini pour le système de fichiers? (tune2fs -l | grep dir_index) Sinon, activez-le. C'est habituellement pour le nouveau RHEL.


    2
    2017-09-27 04:18



    Oui, il est activé, mais suggestion géniale! - BMDan


    Mon option préférée est l'approche newfs, déjà suggérée. Le problème de base est, encore une fois, comme cela a déjà été noté, le balayage linéaire pour gérer la suppression est problématique.

    rm -rf devrait être presque optimal pour un système de fichiers local (NFS serait différent). Mais avec des millions de fichiers, 36 octets par nom de fichier et 4 par inode (une estimation, ne vérifiant pas la valeur de ext3), cela représente 40 * millions, à conserver dans la RAM uniquement pour le répertoire.

    En un rien de temps, vous écrasez la mémoire cache de métadonnées du système de fichiers sous Linux, de sorte que les blocs d'une page du fichier de répertoire soient supprimés pendant que vous utilisez encore une autre partie, pour ensuite atteindre cette page du cache une fois de plus. le fichier est supprimé. Le réglage des performances Linux n’est pas de mon ressort, mais / proc / sys / {vm, fs} / contient probablement quelque chose de pertinent.

    Si vous pouvez vous permettre des temps d'arrêt, vous pouvez envisager d'activer la fonctionnalité dir_index. Il bascule l'index de répertoire de linéaire à quelque chose de beaucoup plus optimal pour la suppression dans les grands répertoires (arbres binaires hachés). tune2fs -O dir_index ... suivi par e2fsck -D travaillerait. Cependant, même si je suis convaincu que cela aiderait avant il y a des problèmes, je ne sais pas comment la conversion (e2fsck avec le -D) lorsqu’il s’agit d’un répertoire v.large existant. Sauvegardes + sucer-it-and-see.


    1
    2017-09-26 12:05



    pubbs.net/201008/squid/… suggère que /proc/sys/fs/vfs_cache_pressure Peut-être la valeur à utiliser, mais je ne sais pas si le répertoire lui-même compte dans le cache de page (parce que c'est ce qu'il est) ou dans le cache d'inode (car, bien qu'il ne s'agisse pas d'un inode, il s'agit de métadonnées FS et regroupées dans ce but) raison). Comme je l'ai dit, le réglage de la machine virtuelle Linux n'est pas mon domaine. Jouez et voyez ce qui aide. - Phil P