rm in einem Verzeichnis mit Millionen von Dateien

Hintergrund: Physischer Server, ungefähr zwei Jahre alt, SATA-Laufwerke mit 7200 U / min, die an eine 3Ware-RAID-Karte angeschlossen sind, ext3 FS-Mounted Noatime und Daten = bestellt, nicht unter verrückter Last, Kernel 2.6.18-92.1.22.el5, Betriebszeit 545 Tage . Directory enthält keine Unterverzeichnisse, nur Millionen kleiner (~ 100 Byte) Dateien, einige größere (ein paar KB).

Wir haben einen Server, der in den letzten Monaten ein bisschen kuckuck gegangen ist, aber wir haben ihn erst neulich bemerkt, als er anfing, nicht in ein Verzeichnis schreiben zu können, weil er zu viele Dateien enthielt. Insbesondere hat es begonnen, diesen Fehler in / var / log / messages auszulösen:

ext3_dx_add_entry: Directory index full!

Auf der fraglichen Festplatte sind noch viele Inodes vorhanden:

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

Ich schätze, das heißt, wir haben das Limit erreicht, wie viele Einträge in der Verzeichnisdatei selbst sein können. Keine Ahnung, wie viele Dateien das sein würden, aber wie Sie sehen können, können es nicht mehr als drei Millionen sein. Nicht dass das gut wäre, wohlgemerkt! Aber das ist Teil einer meiner Fragen: Was genau ist diese Obergrenze? Ist es einstellbar? Bevor ich angeschrien werde - ich möchte es leiser stellen ; Dieses riesige Verzeichnis verursachte alle möglichen Probleme.

Wie auch immer, wir haben das Problem in dem Code aufgespürt, der all diese Dateien generiert hat, und wir haben es korrigiert. Jetzt stecke ich beim Löschen des Verzeichnisses fest.

Ein paar Möglichkeiten hier:

1. rm -rf (dir)

   Ich habe es zuerst versucht. Ich gab es auf und tötete es, nachdem es anderthalb Tage ohne erkennbare Auswirkungen gelaufen war.

2. Unlink (2) im Verzeichnis: Auf jeden Fall eine Überlegung wert, aber die Frage ist, ob es schneller wäre, die Dateien im Verzeichnis über fsck zu löschen, als über Unlink (2). Das heißt, auf die eine oder andere Weise muss ich diese Inodes als unbenutzt markieren. Dies setzt natürlich voraus, dass ich fsck anweisen kann, keine Einträge in den Dateien in / lost + found abzulegen. ansonsten habe ich gerade mein problem verschoben. Neben all den anderen Bedenken muss ich wahrscheinlich einige interne FS-Funktionen aufrufen, nachdem ich etwas mehr darüber gelesen habe, da keine der unlink (2) -Varianten, die ich finden kann, es mir erlauben würde, nur munter zu löschen ein Verzeichnis mit Einträgen darin. Pooh.
3. while [ true ]; do ls -Uf | head -n 10000 | xargs rm -f 2>/dev/null; done )

   Dies ist eigentlich die gekürzte Version; Die eigentliche Version, die ich gerade ausführe und die nur einige Fortschrittsberichte und einen sauberen Stopp hinzufügt, wenn die zu löschenden Dateien ausgehen, ist:

   export i = 0;
   time (while [wahr]; do
     ls -Uf | head -n 3 | grep -qF '.png' || brechen;
     ls -Uf | head -n 10000 | xargs rm -f 2> / dev / null;
     exportiere i = $ (($ i + 10000));
     echo "$ i ...";
   getan )

   Dies scheint ziemlich gut zu funktionieren. Während ich das schreibe, hat es in den letzten 30 Minuten ungefähr 260.000 Dateien gelöscht.

1. Ist, wie oben erwähnt, das Limit für Verzeichniseinträge einstellbar?
2. Warum hat es "echte 7m9.561s / Benutzer 0m0.001s / sys 0m0.001s" gedauert, um eine einzelne Datei zu löschen, die die erste in der Liste war, die von zurückgegeben wurde ls -U, und es hat vielleicht zehn Minuten gedauert , um die ersten 10.000 Einträge mit der zu löschen? Kommando in # 3, aber jetzt schleppt es sich ziemlich glücklich voran? Im Übrigen wurden 260.000 in ungefähr 30 Minuten gelöscht, aber es dauerte jetzt weitere 15 Minuten, um weitere 60.000 zu löschen. Warum die großen Geschwindigkeitsschwankungen?
3. Gibt es einen besseren Weg, um so etwas zu tun? Speichern Sie nicht Millionen von Dateien in einem Verzeichnis. Ich weiß, dass das albern ist, und es wäre auf meiner Uhr nicht passiert. Das Problem zu googeln und durch SF und SO zu schauen, bietet eine Menge Variationen find, die aus mehreren offensichtlichen Gründen nicht wesentlich schneller sein werden als mein Ansatz. Aber hat die Delete-via-Fsck-Idee irgendwelche Beine? Oder etwas ganz anderes? Ich bin gespannt darauf, über den Tellerrand (oder innerhalb der nicht bekannten Box) zu denken.

Letzte Skriptausgabe !:

2970000...
2980000...
2990000...
3000000...
3010000...

real    253m59.331s
user    0m6.061s
sys     5m4.019s

Also drei Millionen Dateien in etwas mehr als vier Stunden gelöscht.

Die data=writebackMount-Option sollte ausprobiert werden, um ein Journaling des Dateisystems zu verhindern. Dies sollte nur während der Löschzeit erfolgen. Es besteht jedoch das Risiko, dass der Server während des Löschvorgangs heruntergefahren oder neu gestartet wird.

Nach dieser Seite ,

Einige Anwendungen zeigen eine sehr deutliche Geschwindigkeitsverbesserung, wenn sie verwendet werden. Beispielsweise können Geschwindigkeitsverbesserungen festgestellt werden (...), wenn Anwendungen große Mengen kleiner Dateien erstellen und löschen.

Die Option wird entweder in fstaboder während des Montagebetriebes, ersetzt data=orderedmit data=writeback. Das Dateisystem mit den zu löschenden Dateien muss neu gemountet werden.

Während eine Hauptursache für dieses Problem die Leistung von ext3 mit Millionen von Dateien ist, ist die eigentliche Hauptursache für dieses Problem anders.

Wenn ein Verzeichnis aufgelistet werden muss, wird readdir () für das Verzeichnis aufgerufen, das eine Liste von Dateien liefert. readdir ist ein posix-Aufruf, aber der echte Linux-Systemaufruf, der hier verwendet wird, heißt 'getdents'. Getdents listet Verzeichniseinträge auf, indem ein Puffer mit Einträgen gefüllt wird.

Das Problem ist hauptsächlich darauf zurückzuführen, dass readdir () eine feste Puffergröße von 32 KB verwendet, um Dateien abzurufen. Wenn ein Verzeichnis größer und größer wird (die Größe nimmt zu, wenn Dateien hinzugefügt werden), wird ext3 langsamer und langsamer, um Einträge abzurufen, und die zusätzliche 32-KB-Puffergröße von readdir reicht nur aus, um einen Bruchteil der Einträge in das Verzeichnis aufzunehmen. Dies führt dazu, dass readdir immer wieder eine Schleife durchläuft und den teuren Systemaufruf immer wieder aufruft.

Zum Beispiel zeigt "ls -1 | wc-l" in einem Testverzeichnis, das ich mit mehr als 2,6 Millionen Dateien erstellt habe, eine große Ausgabe vieler getdent-Systemaufrufe.

$ 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
...

Außerdem war die in diesem Verzeichnis verbrachte Zeit erheblich.

$ time ls -1 | wc -l
2616044

real    0m20.609s
user    0m16.241s
sys 0m3.639s

Die Methode, um dies effizienter zu gestalten, besteht darin, getdents manuell mit einem viel größeren Puffer aufzurufen. Dies verbessert die Leistung erheblich.

Jetzt sollten Sie getdents nicht selbst manuell aufrufen, daher gibt es keine Schnittstelle für die normale Verwendung (sehen Sie in der Manpage nach, ob getdents angezeigt werden!). Sie können es jedoch manuell aufrufen und den Systemaufruf effizienter gestalten.

Dadurch wird die Zeit zum Abrufen dieser Dateien drastisch reduziert. Ich habe ein Programm geschrieben, das dies tut.

/* 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);
}

Dies bekämpft zwar nicht das zugrunde liegende Grundproblem (viele Dateien in einem Dateisystem, das eine schlechte Leistung erbringt). Es ist wahrscheinlich viel, viel schneller als viele der Alternativen, die veröffentlicht werden.

Aus Vorsichtsgründen sollte man das betroffene Verzeichnis entfernen und es anschließend neu erstellen. Verzeichnisse nehmen immer nur an Größe zu und können aufgrund der Größe des Verzeichnisses auch mit wenigen darin enthaltenen Dateien eine schlechte Leistung aufweisen.

Edit: Ich habe das ziemlich aufgeräumt. Es wurde eine Option hinzugefügt, die es Ihnen ermöglicht, zur Laufzeit auf der Befehlszeile zu löschen, und ein paar Baumstamm-Elemente entfernt, die, ehrlich gesagt, im besten Fall fragwürdig waren. Auch wurde gezeigt, Speicherbeschädigung zu produzieren.

Sie können jetzt tun dentls --delete /my/path

Neue Ergebnisse. Basierend auf einem Verzeichnis mit 1,82 Millionen Dateien.

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

War irgendwie überrascht, dass das immer noch so gut funktioniert!

Ist es möglich, alle anderen Dateien aus diesem Dateisystem in einem temporären Speicherort zu sichern, die Partition neu zu formatieren und die Dateien dann wiederherzustellen?

In ext3 gibt es keine Beschränkung pro Verzeichnisdatei, nur die Beschränkung des Dateisystem-Inodes (ich glaube, es gibt eine Beschränkung für die Anzahl der Unterverzeichnisse).

Möglicherweise haben Sie nach dem Entfernen der Dateien weiterhin Probleme.

Wenn ein Verzeichnis Millionen von Dateien enthält, wird der Verzeichniseintrag selbst sehr groß. Der Verzeichniseintrag muss nach jedem Entfernungsvorgang durchsucht werden. Dies dauert für jede Datei unterschiedlich lange, je nachdem, wo sich ihr Eintrag befindet. Leider behält der Verzeichniseintrag auch nach dem Entfernen aller Dateien seine Größe. Weitere Vorgänge, die das Durchsuchen des Verzeichniseintrags erfordern, dauern daher auch dann noch lange, wenn das Verzeichnis jetzt leer ist. Die einzige Möglichkeit, dieses Problem zu lösen, besteht darin, das Verzeichnis umzubenennen, ein neues mit dem alten Namen zu erstellen und alle verbleibenden Dateien auf das neue zu übertragen. Dann löschen Sie die umbenannte.

Ich habe es nicht verglichen, aber dieser Typ hat Folgendes getan :

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

find hat bei mir einfach nicht funktioniert, auch nach dem ändern der ext3 fs parameter wie von den benutzern oben vorgeschlagen. Verbraucht viel zu viel Speicher. Dieses PHP-Skript hat den Trick getan - schnelle, unbedeutende CPU-Auslastung, unbedeutende Speicherauslastung:

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

Ich habe einen Fehlerbericht zu diesem Problem mit find gepostet: http://savannah.gnu.org/bugs/?31961

Ich hatte kürzlich ein ähnliches Problem und konnte den data=writebackVorschlag von ring0 nicht zum Laufen bringen (möglicherweise aufgrund der Tatsache, dass sich die Dateien auf meiner Hauptpartition befinden). Bei der Suche nach Problemumgehungen bin ich auf Folgendes gestoßen:

tune2fs -O ^has_journal <device>

Dadurch wird die Aufzeichnung vollständig deaktiviert, unabhängig von der dataOption, die Sie aktivieren mount. Ich kombinierte dies mit noatimeund die Lautstärke war dir_indexeingestellt, und es schien ziemlich gut zu funktionieren. Der Löschvorgang wurde tatsächlich abgeschlossen, ohne dass ich ihn beenden musste. Mein System reagierte weiterhin und ist jetzt ohne Probleme wieder einsatzbereit (mit aktivierter Journalfunktion).

Stellen Sie sicher, dass Sie:

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

das sollte die Sache auch ein bisschen beschleunigen.

Es ist ein sehr langsamer Befehl. Versuchen:

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

Ist dir_indexfür das Dateisystem eingestellt? ( tune2fs -l | grep dir_index) Wenn nicht, aktivieren Sie es. Normalerweise ist es für neue RHEL aktiviert.

Vor ein paar Jahren habe ich ein Verzeichnis mit 16 Millionen XML- Dateien im /Dateisystem gefunden. Aufgrund der Kritik des Servers haben wir den folgenden Befehl verwendet, der ungefähr 30 Stunden dauerte :

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

Es war eine alte Festplatte mit 7200 U / min , und trotz des E / A-Engpasses und der CPU-Spitzen setzte der alte Webserver seinen Dienst fort.

Meine bevorzugte Option ist der bereits vorgeschlagene newfs-Ansatz. Das Grundproblem ist wiederum, wie bereits erwähnt, die lineare Abtastung, um das Löschen zu handhaben, problematisch.

rm -rfsollte für ein lokales Dateisystem nahezu optimal sein (NFS wäre anders). Aber bei Millionen von Dateien, 36 Bytes pro Dateiname und 4 Bytes pro Inode (eine Schätzung, die den Wert für ext3 nicht überprüft), sind das 40 * Millionen, die nur für das Verzeichnis im RAM gespeichert werden müssen.

Vermutlich zerschlagen Sie den Metadaten-Cache des Dateisystems in Linux, sodass Blöcke für eine Seite der Verzeichnisdatei gelöscht werden, während Sie noch einen anderen Teil verwenden, um diese Seite des Caches beim nächsten Mal erneut aufzurufen Datei wird gelöscht. Linux Performance Tuning ist nicht mein Bereich, aber / proc / sys / {vm, fs} / enthält wahrscheinlich etwas Relevantes.

Wenn Sie sich Ausfallzeiten leisten können, können Sie die Funktion dir_index aktivieren. Es schaltet den Verzeichnisindex von linear auf etwas weitaus Optimaleres zum Löschen in großen Verzeichnissen (gehashte B-Bäume). tune2fs -O dir_index ...gefolgt von e2fsck -Dwürde funktionieren. Obwohl ich zuversichtlich bin, dass dies helfen würde, bevor es Probleme gibt, weiß ich nicht, wie die Konvertierung (e2fsck mit dem -D) ausgeführt wird, wenn ein vorhandenes v.large-Verzeichnis verwendet wird. Backups + Wahnsinn.

Natürlich keine Äpfel zu Äpfeln hier, aber ich habe einen kleinen Test gemacht und folgendes gemacht:

Erstellt 100.000 512-Byte-Dateien in einem Verzeichnis ( ddund /dev/urandomin einer Schleife). Ich habe die Zeit vergessen, aber es dauerte ungefähr 15 Minuten, um diese Dateien zu erstellen.

Führen Sie die folgenden Schritte aus, um diese Dateien zu löschen:

ls -1 | wc -l && time find . -type f -delete

100000

real    0m4.208s
user    0m0.270s
sys     0m3.930s 

Dies ist eine Pentium 4-Box mit 2,8 GHz (einige hundert GB IDE mit 7200 U / min, glaube ich; EXT3). Kernel 2.6.27.

Manchmal kann Perl in solchen Fällen Wunder wirken. Haben Sie bereits versucht, ob ein kleines Skript wie dieses Bash und die grundlegenden Shell-Befehle übertreffen könnte?

#!/usr/bin/perl 
open(ANNOYINGDIR,"/path/to/your/directory");
@files = grep("/*\.png/", readdir(ANNOYINGDIR));
close(ANNOYINGDIR);

for (@files) {
    printf "Deleting %s\n",$_;
    unlink $_;
}

Oder ein anderer, vielleicht sogar noch schnellerer Perl-Ansatz:

#!/usr/bin/perl
unlink(glob("/path/to/your/directory/*.png")) or die("Could not delete files, this happened: $!");

EDIT: Ich habe gerade meine Perl-Skripte ausprobiert. Je ausführlicher man etwas richtig macht. In meinem Fall habe ich dies mit einem virtuellen Server mit 256 MB RAM und einer halben Million Dateien versucht.

time find /test/directory | xargs rm Ergebnisse:

real    2m27.631s
user    0m1.088s
sys     0m13.229s

verglichen mit

time perl -e 'opendir(FOO,"./"); @files = readdir(FOO); closedir(FOO); for (@files) { unlink $_; }'

real    0m59.042s
user    0m0.888s
sys     0m18.737s

Soweit ich mich erinnere, ist das Löschen von Inodes in ext-Dateisystemen O (n ^ 2). Je mehr Dateien Sie löschen, desto schneller wird der Rest ausgeführt.

Es gab ein einziges Mal, dass ich mit einem ähnlichen Problem konfrontiert war (obwohl meine Schätzungen eine Löschzeit von ~ 7 Stunden betrachteten), und am Ende ging die von JFTUGA vorgeschlagene Route im ersten Kommentar .

Nun, das ist keine richtige Antwort, aber ...

Wäre es möglich, das Dateisystem nach ext4 zu konvertieren und zu sehen, ob sich die Dinge ändern?

Okay, das wurde im Rest des Threads auf verschiedene Arten abgedeckt, aber ich dachte, ich würde meine zwei Cent einwerfen. Der Leistungsschuldige in Ihrem Fall ist wahrscheinlich readdir. Sie erhalten eine Liste von Dateien zurück, die auf der Festplatte nicht unbedingt in irgendeiner Weise sequentiell sind, wodurch beim Trennen der Verknüpfung überall auf die Festplatte zugegriffen wird. Die Dateien sind so klein, dass der Vorgang zum Aufheben der Verknüpfung wahrscheinlich nicht zu weit aus dem Speicherplatz herausspringt. Wenn Sie readdir lesen und dann nach aufsteigendem Inode sortieren, erhalten Sie wahrscheinlich eine bessere Leistung. Also readdir in ram (sortiere nach inode) -> unlink -> profit.

Inode ist hier eine grobe Annäherung, denke ich .. aber basierend auf Ihrem Anwendungsfall könnte es ziemlich genau sein ...

Ich hätte wahrscheinlich einen C-Compiler herausgepeitscht und das moralische Äquivalent Ihres Skripts erstellt. Das heißt, verwenden Sie opendir(3), um ein Verzeichnis-Handle abzurufen, und dann readdir(3), um den Namen der Dateien abzurufen. Führen Sie dann beim Aufheben der Verknüpfung eine Zusammenfassung der Dateien durch und drucken Sie ab und zu "% d Dateien gelöscht" (und möglicherweise die abgelaufene Zeit oder den aktuellen Zeitstempel).

Ich erwarte nicht, dass es merklich schneller ist als die Shell-Skript-Version. Ich bin es nur gewohnt, hin und wieder den Compiler rauszureißen, entweder weil es keine saubere Möglichkeit gibt, das zu tun, was ich von der Shell will, oder weil Obwohl es in der Shell machbar ist, ist es auf diese Weise unproduktiv langsam.

Wahrscheinlich treten beim Umschreiben des Verzeichnisses Probleme auf. Versuchen Sie zuerst, die neuesten Dateien zu löschen. Sehen Sie sich die Mount-Optionen an, mit denen das Zurückschreiben auf die Festplatte verzögert wird.

Versuchen Sie für eine Fortschrittsanzeige etwas wie rm -rv /mystuff 2>&1 | pv -brtl > /dev/null

So lösche ich die Millionen von Tracedateien, die manchmal auf einem großen Oracle-Datenbankserver gesammelt werden können:

for i in /u*/app/*/diag/*/*/*/trace/*.tr? ; do rm $i; echo -n . ;  done

Ich stelle fest, dass dies zu einer relativ langsamen Löschung führt, die sich nur geringfügig auf die Serverleistung auswirkt, normalerweise in der Größenordnung von einer Stunde pro Million Dateien bei einem "typischen" 10.000-IOPS-Setup.

Oft dauert es mehrere Minuten, bis die Verzeichnisse durchsucht, die erste Dateiliste erstellt und die erste Datei gelöscht wurde. Von da an und weiter, a. wird für jede gelöschte Datei zurückgemeldet.

Die Verzögerung, die durch das Echo des Terminals verursacht wird, hat sich als ausreichend verzögert erwiesen, um eine signifikante Belastung während des Löschvorgangs zu verhindern.

Sie könnten 'xargs'-Parallelisierungsfunktionen verwenden:

ls -1|xargs -P nb_concurrent_jobs -n nb_files_by_job rm -rf

ls|cut -c -4|sort|uniq|awk '{ print "rm -rf " $1 }' | sh -x

Tatsächlich ist dieses etwas besser, wenn die von Ihnen verwendete Shell eine Befehlszeilenerweiterung ausführt:

ls|cut -c -4|sort|uniq|awk '{ print "echo " $1 ";rm -rf " $1 "*"}' |sh