rm в каталоге с миллионами файлов

Фон: физический сервер, около двух лет, диски SATA с частотой 7200 об /мин, подключенные к RAID-карте 3Ware, ext3 FS, установленный noatime, и данные = упорядоченные, а не под сумасшедшей нагрузкой, ядро ​​2.6.18-92.1.22 .el5, время безотказной работы 545 дней. Каталог не содержит каких-либо подкаталогов, всего миллионы небольших (~ 100 байт) файлов, с некоторыми более крупными (несколько КБ).

В течение последних нескольких месяцев у нас есть сервер, который немного кукушка, но мы заметили его только на тот день, когда он начал не писать в каталог из-за того, что он содержит слишком много файлов. В частности, он начал метать эту ошибку в /var /log /messages:

ext3_dx_add_entry: Directory index full!

В этом диске есть много оставшихся инодов:

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

Итак, я предполагаю, что это означает, что мы достигли предела того, сколько записей может быть в самом файле каталога. Не знаю, сколько файлов было бы, но это не может быть больше, как вы можете видеть, чем три миллиона или около того. Не то чтобы это хорошо, заметьте! Но это один из моих вопросов: что это за верхний предел? Это настраивается? Прежде чем я закричаю: «Я хочу настроить его вниз ; этот огромный каталог вызвал всевозможные проблемы.

В любом случае, мы отследили проблему в коде, который генерировал все эти файлы, и мы исправили его. Теперь я застрял в удалении каталога.

Несколько вариантов:

  1. rm -rf (dir)

    Я попробовал это первым. Я сдался и убил его после того, как он проработал полтора дня без какого-либо заметного воздействия.

  2. unlink (2) в каталоге: определенно стоит рассмотреть, но вопрос в том, будет ли быстрее удалять файлы внутри каталога через fsck, чем удалять через unlink (2). То есть, так или иначе, я должен отметить эти иноды как неиспользуемые. Это предполагает, конечно, что я могу сказать fsck не отбрасывать записи в файлы в /lost + found; в противном случае, я только что перенесла свою проблему. В дополнение ко всем остальным проблемам, после прочтения об этом немного больше, оказывается, мне, вероятно, придется называть некоторые внутренние функции FS, так как ни один из вариантов unlink (2), которые я могу найти, не позволил бы мне просто беспечно удалить каталог с записями в нем. Пух.
  3. while [ true ]; do ls -Uf | head -n 10000 | xargs rm -f 2>/dev/null; done )

    Это фактически сокращенная версия; реальный, который я запускаю, что просто добавляет некоторые отчеты о проделанной работе и чистую остановку, когда у нас заканчиваются файлы для удаления, это:

    export i = 0;
    время (while [true]; do
      ls -Uf | head -n 3 | grep -qF '.png' || ломать;
      ls -Uf | head -n 10000 | xargs rm -f 2> /dev /null;
      экспорт i = $ (($ i + 10000));
      echo "$ i ...";
    сделано)

    Это, кажется, работает довольно хорошо. Когда я пишу это, он удалил 260 000 файлов за последние тридцать минут или около того.

Теперь, для вопросов:
  1. Как упоминалось выше, настраивается ли ограничение на запись для каждого каталога?
  2. Почему для удаления одного файла, который был первым в списке, возвращаемом ls -U, и потребовалось «real 7m9.561s /user 0m0.001s /sys 0m0.001s», и потребовалось, пожалуй, десять минут, чтобы удалить первые 10 000 записей с помощью команды в № 3, но теперь она довольно хорошо тянет? В этом случае он удалил 260 000 примерно за тридцать минут, но теперь понадобилось еще пятнадцать минут, чтобы удалить еще 60 000. Почему огромные колебания в скорости?
  3. Есть ли лучший способ сделать такие вещи? Не хранить миллионы файлов в каталоге; Я знаю, что это глупо, и это не случилось бы на моих часах. Переключение проблемы и просмотр SF и SO предлагает множество вариантов find, которые не будут значительно быстрее, чем мой подход по нескольким очевидным причинам. Но есть ли у идеи delete-through-fsck какие-то ноги? Или что-то еще?Я очень хочу услышать из-за коробки (или внутри-не-хорошо известную коробку).
Спасибо, что прочитали небольшой роман; не стесняйтесь задавать вопросы, и я обязательно отвечу. Я также обновляю вопрос с окончательным количеством файлов и как долго будет выполняться сценарий удаления, когда у меня есть это.

Окончательный вывод скрипта:

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

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

Итак, три миллиона файлов удалены бит за четыре часа.

96 голосов | спросил BMDan 23 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 23 Sep 2010 03:57:33 +0400 2010, 03:57:33

23 ответа


29

Параметры монтирования data=writeback заслуживают рассмотрения, чтобы предотвратить журналирование файловой системы. Это должно быть сделано только во время удаления, однако существует риск, если сервер отключается или перезагружается во время операции удаления.

Согласно этой странице ,

  

Некоторые приложения показывают очень значительное улучшение скорости при его использовании. Например, улучшения скорости можно увидеть (...), когда приложения создают и удаляют большие объемы небольших файлов.

Параметр устанавливается либо в fstab, либо во время операции монтирования, заменяя data=ordered на data=writeback. Файловая система, содержащая файлы, подлежащие удалению, должна быть перемонтирована.

ответил Ring Ø 26 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 26 Sep 2010 09:49:38 +0400 2010, 09:49:38
72

В то время как основной причиной этой проблемы является производительность ext3 с миллионами файлов, фактическая основная причина этой проблемы отличается.

Когда каталог должен быть указан, readdir () вызывается в каталоге, который дает список файлов. readdir - вызов posix, но используемый здесь системный вызов Linux называется «getdents». Getdents список записей каталога, заполнив буфер с помощью записей.

Проблема в основном сводится к тому, что readdir () использует фиксированный размер буфера 32 Кбит для извлечения файлов. Поскольку каталог становится все больше и больше (размер увеличивается с добавлением файлов), ext3 получает медленнее и медленнее, чтобы извлекать записи, а размер буфера для дополнительного 32-разрядного буфера чтения достаточен для того, чтобы включить часть записей в каталог. Это заставляет readdir зацикливаться снова и снова и вызывать дорогостоящий системный вызов снова и снова.

Например, в тестовом каталоге, который я создал с более чем 2.6 миллионами файлов внутри, запуск «ls -1 | wc-l» показывает большой вывод strace из многих системных вызовов 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
...

Кроме того, время, проведенное в этом каталоге, было значительным.

$ time ls -1 | wc -l
2616044

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

Метод, чтобы сделать это более эффективным процессом, - это вызов getdents вручную с гораздо большим буфером. Это значительно улучшает производительность.

Теперь вы не должны сами вызывать getdents вручную, поэтому интерфейс не существует, чтобы использовать его в обычном режиме (проверьте man-страницу для getdents, чтобы видеть!), однако вы можете вызвать его вручную и сделать ваш способ вызова вызова системы более эффективен.

Это значительно сокращает время, необходимое для получения этих файлов. Я написал программу, которая делает это.

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

В то время как это не противоречит основной фундаментальной проблеме (много файлов, в файловой системе, которая плохо работает на ней). Скорее всего, это будет намного быстрее, чем многие из предложенных альтернатив.

В качестве предусмотрительности следует удалить зараженный каталог и переделать его после. Каталоги только когда-либо увеличиваются в размере и могут оставаться плохо выполненными даже с несколькими файлами внутри из-за размера каталога.

Изменить: Я немного почистил это. Добавлена ​​опция, позволяющая вам удалять в командной строке во время выполнения и удалять кучу материала, который, честно оглядываясь, в лучшем случае сомневался. Также было показано, что происходит повреждение памяти.

Теперь вы можете выполнить dentls --delete /my/path

Новые результаты. Основано на директории с 1.82 миллионами файлов.

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

Был удивлен, что это все так хорошо работает!

ответил Matthew Ife 6 72011vEurope/Moscow11bEurope/MoscowSun, 06 Nov 2011 23:06:31 +0400 2011, 23:06:31
31

Можно ли сделать резервную копию всех других файлов из этой файловой системы во временное хранилище, переформатировать раздел и затем восстановить файлы?

ответил jftuga 23 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 23 Sep 2010 04:27:26 +0400 2010, 04:27:26
11

В файле ext3 нет ограничения на файл каталога в файле ext3, но только ограничение файловой системы inode (я думаю, что существует ограничение на количество подкаталогов).

У вас могут быть проблемы после удаления файлов.

Когда каталог содержит миллионы файлов, сама запись каталога становится очень большой. Запись каталога должна быть проверена для каждой операции удаления, и для каждого файла требуется различное количество времени, в зависимости от того, где находится его запись. К сожалению, даже после того, как все файлы были удалены, запись в каталоге сохраняет свой размер. Поэтому дальнейшие операции, требующие сканирования записи в каталоге, по-прежнему занимают много времени, даже если каталог теперь пуст. Единственный способ решить эту проблему - переименовать каталог, создать новый со старым именем и перенести все остальные файлы в новый. Затем удалите переименованный.

ответил Alex J. Roberts 23 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 23 Sep 2010 09:45:40 +0400 2010, 09:45:40
5

Я не тестировал это, но этот парень сделал :

rsync -a --delete ./emptyDirectoty/ ./hugeDirectory/
ответил Alix Axel 4 J0000006Europe/Moscow 2013, 15:52:38
4

find просто не работает для меня, даже после изменения параметров ext3 fs, как это было предложено выше. Потребление слишком много памяти. Этот скрипт PHP сделал трюк - быстрое, незначительное использование ЦП, незначительное использование памяти:

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

Я отправил сообщение об ошибке с этой проблемой: http://savannah.gnu.org /ошибки /? 31961

ответил Alexandre 23 ThuEurope/Moscow2010-12-23T22:54:40+03:00Europe/Moscow12bEurope/MoscowThu, 23 Dec 2010 22:54:40 +0300 2010, 22:54:40
3

Недавно я столкнулся с аналогичной проблемой и не смог получить предложение ring0 data=writeback для работы (возможно, из-за того, что файлы находятся на моем основном разделе). Изучая обходные пути, я наткнулся на это:

tune2fs -O ^has_journal <device>

Это полностью отключит ведение журнала, независимо от параметра data, чтобы указать mount. Я объединил это с noatime, а том имел dir_index, и он, похоже, работал очень хорошо. Удаление действительно закончилось без меня, чтобы его убить, моя система оставалась отзывчивой, и теперь она работает и работает (с журналированием) без проблем.

ответил Matthew Read 24 AMpTue, 24 Apr 2012 02:29:17 +040029Tuesday 2012, 02:29:17
3

Убедитесь, что вы сделали:

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

, который также должен ускорить работу.

ответил karmawhore 27 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 27 Sep 2010 06:03:30 +0400 2010, 06:03:30
2

ls очень медленная команда. Попробуйте:

find /dir_to_delete ! -iname "*.png" -type f -delete
ответил bindbn 23 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 23 Sep 2010 08:04:52 +0400 2010, 08:04:52
2

Установлен ли dir_index для файловой системы? (tune2fs -l | grep dir_index) Если нет, включите его. Это обычно для нового RHEL.

ответил sam 27 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 27 Sep 2010 08:18:31 +0400 2010, 08:18:31
1

Мой предпочтительный вариант - это уже предложенный метод newfs. Основная проблема заключается в том, что, как уже отмечалось, линейное сканирование для обработки удаления проблематично.

rm -rf должен быть близок к оптимальной для локальной файловой системы (NFS будет отличаться). Но в миллионах файлов 36 байтов на каждое имя файла и 4 на индексный дескриптор (предположение, не проверяющее значение для ext3), то есть 40 * миллионов, должны храниться в ОЗУ только для каталога.

Угадайте, что вы перегружаете кэш-память метаданных файловой системы в Linux, так что блоки для одной страницы файла каталога удаляются, пока вы все еще используете другую часть, чтобы снова ударить эту страницу кеша когда следующий файл будет удален. Настройка производительности Linux не является моей областью, но /proc /sys /{vm, fs} /вероятно содержит что-то важное.

Если вы можете позволить себе время простоя, вы можете включить функцию dir_index. Он переключает индекс каталога с линейного на нечто гораздо более оптимальное для удаления в больших каталогах (хешированные b-деревья). tune2fs -O dir_index ..., за которым следует e2fsck -D. Однако, хотя я уверен, что это помогло бы до возникнуть проблемы, я не знаю, как выполняется преобразование (e2fsck с помощью -D) при работе с существующим v.large каталог. Резервные копии + сосать-и-видеть.

ответил Phil P 26 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 26 Sep 2010 16:05:41 +0400 2010, 16:05:41
1

Очевидно, что яблоки для яблок здесь, но я немного настроил тест и сделал следующее:

Создал 100 000 512-байтных файлов в каталоге (dd и /dev/urandom в цикле); забыл время, но для создания этих файлов потребовалось примерно 15 минут.

Чтобы удалить указанные файлы, выполните следующие действия:

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

100000

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

Это Pentium 4 2.8GHz box (пара сотен GB IDE 7200 RPM, я думаю, EXT3). Ядро 2.6.27.

ответил gravyface 26 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 26 Sep 2010 19:33:12 +0400 2010, 19:33:12
1

Иногда Perl может творить чудеса в подобных случаях. Вы уже пробовали, если небольшой скрипт, такой как это, может превосходить bash и основные команды оболочки?

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

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

Или другой, возможно, даже быстрее, подход Perl:

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

EDIT: Я просто попробовал свои скрипты в Perl. Более многословный делает что-то правильно. В моем случае я попробовал это с виртуальным сервером с ОЗУ 256 МБ и полмиллиона файлов.

time find /test/directory | xargs rm результаты:

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

по сравнению с

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

real    0m59.042s
user    0m0.888s
sys     0m18.737s
ответил Janne Pikkarainen 27 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 27 Sep 2010 19:24:05 +0400 2010, 19:24:05
1

Из того, что я помню, удаление inodes в ext файловых системах - O (n ^ 2), поэтому чем больше файлов вы удаляете, тем быстрее будет оставлено.

Был один раз, когда мне приходилось сталкиваться с подобной проблемой (хотя мои оценки смотрели на время удаления ~ 7 часов), в конце концов был предложен маршрут jftuga в первом комментарии .

ответил Hubert Kario 30 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 30 Sep 2010 04:33:38 +0400 2010, 04:33:38
1

Несколько лет назад я нашел каталог с 16 миллионами XML файлов в файловой системе /. Из-за критики сервера мы использовали следующую команду, которая потребовала 30 часов :

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

Это был старый 7200 rpm hdd, и, несмотря на узкие места IO и всплески процессора, старый веб-сервер продолжил обслуживание.

ответил a_foaley 13 Maypm16 2016, 16:44:04
0

Ну, это не реальный ответ, но ...

Можно ли преобразовать файловую систему в ext4 и посмотреть, не изменились ли какие-либо вещи?

ответил marcoc 27 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 27 Sep 2010 19:02:48 +0400 2010, 19:02:48
0

Хорошо, что это было покрыто различными способами в остальной части потока, но я думал, что брошу свои два цента. Преступник в вашем случае, вероятно, доступен для чтения. Вы возвращаете список файлов, которые не обязательно являются случайными на диске, что вызывает дисковый доступ повсюду, когда вы отсоединяетесь. Файлы достаточно малы, чтобы операция отключения связи, вероятно, не переместилась слишком сильно, чтобы обнулить пространство. Если вы читаете dir, а затем сортируете по возрастанию inode, вы, вероятно, получите лучшую производительность. Поэтому readdir в ram (sort by inode) -> unlink -> прибыль.

Inode - грубое приближение здесь, я думаю .. но исходя из вашего варианта использования, он может быть довольно точным ...

ответил MattyB 30 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 30 Sep 2010 03:31:44 +0400 2010, 03:31:44
0

Я бы, наверное, выбил компилятор C и сделал моральный эквивалент вашего скрипта. То есть, используйте opendir(3), чтобы получить дескриптор каталога, затем используйте readdir(3), чтобы получить имя файла, а затем подсчитайте файлы, когда я отсоединяю их и раз в то время печатайте «% d-файлов» (и, возможно, прошедшее время или текущую отметку времени).

Я не ожидаю, что это будет заметно быстрее, чем версия сценария оболочки, просто я привык к тому, что иногда приходится копировать компилятор, потому что нет чистого способа сделать то, что я хочу от shell или потому что, будучи выполнимым в оболочке, это непродуктивно замедляет этот путь.

ответил Vatine 26 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 26 Sep 2010 16:24:09 +0400 2010, 16:24:09
0

Вероятно, вы столкнетесь с проблемами перезаписи с каталогом. Сначала попробуйте удалить новейшие файлы. Посмотрите варианты монтирования, которые откладывают обратную запись на диск.

Для панели выполнения попробуйте запустить что-то вроде rm -rv /mystuff 2>&1 | pv -brtl > /dev/null

ответил BillThor 26 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 26 Sep 2010 22:16:36 +0400 2010, 22:16:36
0

Вот как я удаляю миллионы файлов трассировки, которые иногда могут собираться на большом сервере базы данных Oracle:

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

Я нахожу, что это приводит к довольно медленному удалению, которое оказывает малое влияние на производительность сервера, обычно что-то похожее на час на миллион файлов на «типичную» настройку 10 000 IOPS.

Чаще всего за несколько минут до сканирования каталогов, сгенерированного исходного списка файлов и удаления первого файла. Оттуда и дальше. для каждого удаляемого файла.

Задержка, вызванная эхом на терминал, доказала достаточную задержку, чтобы предотвратить значительную нагрузку при продолжении удаления.

ответил Roy 10 +04002014-10-10T13:31:59+04:00312014bEurope/MoscowFri, 10 Oct 2014 13:31:59 +0400 2014, 13:31:59
-1

Вы можете использовать функции распараллеливания «xargs»:

ls -1|xargs -P nb_concurrent_jobs -n nb_files_by_job rm -rf
ответил Jeremy 30 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 30 Sep 2010 18:30:22 +0400 2010, 18:30:22
-2
ls|cut -c -4|sort|uniq|awk '{ print "rm -rf " $1 }' | sh -x
ответил karmawhore 30 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 30 Sep 2010 18:06:54 +0400 2010, 18:06:54
-2

на самом деле, это немного лучше, если используемая оболочка расширяет расширение командной строки:

ls|cut -c -4|sort|uniq|awk '{ print "echo " $1 ";rm -rf " $1 "*"}' |sh
ответил 1 +04002010-10-01T00:02:03+04:00312010bEurope/MoscowFri, 01 Oct 2010 00:02:03 +0400 2010, 00:02:03

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132