rm包含数百万个文件的目录

背景：物理服务器，已有大约两年的历史，已将7200-RPM SATA驱动器连接到3Ware RAID卡，安装了ext3 FS的noatime和data = ordered，没有疯狂的负载，内核2.6.18-92.1.22.el5，正常运行时间为545天。目录不包含任何子目录，仅包含数百万个小文件（〜100字节），还有一些大文件（几KB）。

在过去的几个月中，我们的服务器出现了一些故障，但是直到几天前，由于包含太多文件，它才开始无法写入目录，因此我们才注意到它。具体来说，它开始在/ var / log / messages中引发此错误：

ext3_dx_add_entry: Directory index full!

有问题的磁盘上还有许多索引节点剩余：

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

因此，我猜测这意味着我们达到了目录文件本身中可以包含多少个条目的限制。不知道会有多少个文件，但是正如您所看到的，最多不能超过300万个左右。不好意思，请注意！但这是我的问题之一：上限到底是多少？可调吗？在我得到大叫，我想调整它下来 ; 这个巨大的目录引起了各种各样的问题。

无论如何，我们在生成所有这些文件的代码中找到了问题，并已进行了纠正。现在，我一直坚持删除目录。

这里有一些选择：

1. rm -rf (dir)

   我先试了 在运行了一天半之后，没有任何明显的影响，我放弃并杀死了它。

2. 目录上的unlink（2）：绝对值得考虑，但问题是，通过fsck删除目录中的文件是否比通过unlink（2）删除要快。也就是说，我必须将那些inode标记为未使用。当然，这是假定我可以告诉fsck不要将条目丢弃到/ lost + found中的文件中。否则，我只是解决了我的问题。除了所有其他问题外，在阅读了更多内容之后，事实证明我可能必须调用一些内部FS函数，因为我找不到的unlink（2）变体都不允许我随意删除在其中包含条目的目录。呸。
3. while [ true ]; do ls -Uf | head -n 10000 | xargs rm -f 2>/dev/null; done )

   这实际上是缩短的版本；我正在运行的真正的文件是：当我们用完要删除的文件时，它只是添加了一些进度报告和干净的停止位置：

   出口i = 0;
   时间（[[true];
     ls -Uf | 头-n 3 | grep -qF'.png'|| 打破;
     ls -Uf | 头-n 10000 | xargs rm -f 2> / dev / null;
     出口i = $（（（$ i + 10000））;
     回显“ $ i ...”；
   完成）

   这似乎工作得很好。在我撰写本文时，它在过去三十分钟左右的时间内删除了260,000个文件。

1. 如上所述，每个目录的条目限制是否可调？
2. 为什么要用“真实的7m9.561s /用户0m0.001s / sys 0m0.001s”来删除单个文件，该文件是所返回的列表中的第一个文件，而删除该文件ls -U的前10,000个条目可能要花10分钟的时间＃3中的命令，但现在它运行得很愉快？为此，它在大约30分钟内删除了260,000，但是现在又花了15分钟才删除了60,000。为什么会出现巨大的速度波动？
3. 有没有更好的方法来做这种事情？不在目录中存储数百万个文件；我知道那很傻，而且在我的手表上不会发生。探究问题并仔细研究SF和SO会发现很多变化find，但由于一些不言而喻的原因，这些变化不会比我的方法快得多。但是通过fsck删除的想法有什么作用吗？还是完全其他？我渴望听到开箱即用（或不为人所知的盒子）的想法。

最终脚本输出！：

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

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

因此，在四个小时内删除了300万个文件。

data=writeback应该尝试使用mount选项，以防止文件系统记录日志。仅应在删除期间执行此操作，但是如果在删除操作过程中关闭服务器或重新引导服务器，则存在风险。

根据此页面，

使用某些应用程序后，速度会显着提高。例如，当应用程序创建和删除大量小文件时，可以看到（...）速度提高。

的选项被设置在任一fstab或安装操作过程中，替换data=ordered与data=writeback。包含要删除文件的文件系统必须重新安装。

尽管此问题的主要原因是具有数百万个文件的ext3性能，但此问题的实际根本原因有所不同。

当需要列出目录时，将在目录上调用readdir（），从而产生文件列表。readdir是posix调用，但是此处使用的实际Linux系统调用称为“ getdents”。Getdents通过使用条目填充缓冲区来列出目录条目。

问题主要是由于readdir（）使用固定大小为32Kb的缓冲区来提取文件。随着目录变得越来越大（随着文件的添加，大小也随之增加），ext3越来越慢地获取条目，而附加的readdir的32Kb缓冲区大小仅足以在目录中包含一部分条目。这导致readdir反复循环并反复调用昂贵的系统调用。

例如，在我创建的包含超过260万个文件的测试目录中，运行“ ls -1 | wc-l”显示了许多getdent系统调用的大量strace输出。

$ 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，因此不存在可以正常使用它的界面（请查看手册页中的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

新结果。基于包含182万个文件的目录。

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

感到惊讶的是，它仍然如此有效！

是否可以将所有其他文件从此文件系统备份到临时存储位置，重新格式化分区，然后还原文件？

ext3中没有每个目录文件的限制，只是文件系统inode的限制（尽管我认为子目录的数量有限制）。

删除文件后，您仍然可能有问题。

当目录包含数百万个文件时，目录条目本身将变得非常大。必须对目录项进行每次删除操作的扫描，并且每个文件要花费不同的时间，具体取决于其条目所在的位置。不幸的是，即使在删除所有文件之后，目录条目仍保留其大小。因此，即使目录现在为空，需要扫描目录条目的其他操作仍将花费很长时间。解决该问题的唯一方法是重命名目录，使用旧名称创建新目录，然后将所有剩余文件传输到新目录。然后删除重命名的。

我还没有进行基准测试，但是这个家伙做到了：

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

即使更改了上述用户建议的ext3 fs的参数，find对我也不起作用。消耗过多的内存。这个PHP脚本达到了目的-快速，微不足道的CPU使用率，微不足道的内存使用率：

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

我发布了有关此查找问题的错误报告：http : //savannah.gnu.org/bugs/?31961

我最近遇到了类似的问题，无法获得ring0的data=writeback建议（可能是由于文件位于我的主分区上）。在研究解决方法时，我偶然发现了这一点：

tune2fs -O ^has_journal <device>

无论data给的选项如何，此操作都会完全关闭日记功能mount。我将其与结合在一起，noatime并且音量已dir_index确定，并且看起来效果很好。删除实际上完成了，而无需我杀死它，我的系统保持了响应能力，并且现在可以备份并运行（重新启用日记），没有任何问题。

确保您这样做：

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

这也应该加快速度。

ls非常慢的命令。尝试：

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

被dir_index设置为文件系统？（tune2fs -l | grep dir_index）如果没有，请启用它。通常在新的RHEL上启用。

几年前，我在文件系统中找到一个包含1600万个XML文件的 /目录。由于服务器的问题，我们使用以下命令花费了大约30个小时来完成：

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

这是一个旧的7200 rpm硬盘，尽管存在IO瓶颈和CPU高峰，但旧的Web服务器仍继续其服务。

我建议的首选方法是已经建议的newfs方法。再次如上所述，基本问题是处理删除的线性扫描是有问题的。

rm -rf对于本地文件系统，它应该接近最佳状态（NFS会有所不同）。但是对于数百万个文件，每个文件名36个字节和每个inode 4个（猜测，不检查ext3的值），即40 *百万，仅保留在RAM中用于目录。

猜想，您正在破坏Linux中的文件系统元数据缓存，以便在您仍在使用另一部分时清除目录文件的一页的块，而仅在下一页再次击中该页面的缓存时，文件被删除。Linux性能调整不是我的专长，但是/ proc / sys / {vm，fs} /可能包含一些相关的内容。

如果您可以承受停机时间，则可以考虑启用dir_index功能。它将目录索引从线性切换到更适合在大型目录（散列的b树）中删除的最佳索引。 tune2fs -O dir_index ...其次e2fsck -D将工作。但是，尽管我确信这会在出现问题之前有所帮助，但是我不知道-D在处理现有的v.large目录时转换（带有的e2fsck ）如何执行。备份+随便看看。

显然这里不是苹果对苹果，但我进行了一些测试，并进行了以下操作：

在一个目录（dd和/dev/urandom循环）中创建了100,000个512字节文件；忘记为它计时，但是创建这些文件大约花费了15分钟。

运行以下命令删除所述文件：

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

100000

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

这是奔腾4 2.8GHz盒子（我认为是几百GB IDE 7200 RPM； EXT3）。内核2.6.27。

在这种情况下，有时Perl可以创造奇迹。您是否已经尝试过像这样的小脚本胜过bash和基本的shell命令？

#!/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: $!");

编辑：我只是尝试了我的Perl脚本。越冗长的人就做对了。就我而言，我在具有256 MB RAM和50万个文件的虚拟服务器上进行了尝试。

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

我记得在ext文件系统中删除inode的信息是O（n ^ 2），因此删除的文件越多，剩下的文件就会越快。

曾经有一次我遇到类似的问题（尽管我的估计是大约7小时的删除时间），最后在第一条评论中使用了jftuga建议的路线。

好吧，这不是一个真正的答案，但是...

是否可以将文件系统转换为ext4并查看情况是否发生变化？

好了，线程的其余部分已经以各种方式解决了这个问题，但是我想我会投入两分钱。您遇到的性能问题可能是readdir。您将获得一个文件列表，这些文件在磁盘上不一定以任何方式顺序排列，这会导致在取消链接时在所有位置进行磁盘访问。文件足够小，以至于取消链接操作可能不会跳得太多，从而使空间清零。如果您先读取dir，然后按升序将inode排序，则可能会获得更好的性能。因此将readdir放入ram（按inode排序）->取消链接->获利。

我认为Inode是一个大概的近似值..但是根据您的用例，它可能是相当准确的...

我可能会淘汰一个C编译器并完成与您的脚本相同的工作。也就是说，用于opendir(3)获取目录句柄，然后用于readdir(3)获取文件名，然后在取消链接时对文件进行计数，并偶尔打印“％d个文件已删除”（可能经过的时间或当前时间戳记）。

我不希望它比shell脚本版本快得多，只是因为我曾经不得不不时地淘汰编译器，因为没有干净的方法可以从shell中完成所需的工作，或者因为尽管可以在shell中使用，但这种方式的生产效率却很低。

您可能会遇到目录重写问题。尝试先删除最新文件。查看将推迟写回磁盘的安装选项。

对于进度条，请尝试运行类似 rm -rv /mystuff 2>&1 | pv -brtl > /dev/null

这是我删除有时可能在大型Oracle数据库服务器上收集的数百万个跟踪文件的方法：

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

我发现这导致删除速度相当慢，对服务器性能的影响较低，通常在“典型”的10,000 IOPS设置中，每百万个文件大约需要一个小时。

扫描目录，生成初始文件列表和删除第一个文件通常需要几分钟。从那里开始，对于每个删除的文件回显。

事实证明，由回显到终端引起的延迟足以防止删除进行中的任何重大负载。

您可以使用“ xargs”并行化功能：

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

实际上，如果您使用的shell进行命令行扩展，则此方法会更好一些：

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