删除文件花费的时间太长

简短版本：rm -rf mydir，mydir（递归地）包含250万个文件，在大多数空闲的计算机上大约需要12个小时。

更多信息：大部分要删除的文件是指向其他目录中文件的硬链接（实际上，删除的目录是由进行的最旧的备份rsnapshot；rm命令实际上是由提供的rsnapshot）。因此，大多数目录条目都将被删除-文件内容本身并不多。它大约是几十GB。

我不确定btrfs是罪魁祸首。我记得在开始使用备份之前，备份也非常慢btrfs，但是我不确定删除是否缓慢。

该计算机是具有4 GB RAM的Intel Core i5 2.67 GHz。它有两个SATA磁盘：一个有操作系统和其他一些东西，备份磁盘是1 TB WDC WD1002FAEX-00Z3A0。主板是华硕P7P55D。

编辑：该机器是Linux的Debian狂潮3.16.3-2~bpo70+1。这是文件系统的挂载方式：

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

编辑：使用rsync -a --delete /some/empty/dir mydir大约需要6个小时。与相比有很大的改进rm -rf，但我认为仍然太多了。（为什么rsync会比rm以下解释更快：“ [大多数文件系统以btree格式存储其目录结构，删除文件的顺序[...]很重要。执行取消链接时需要避免重新平衡btree。 .... rsync -a --delete...按顺序删除”）

编辑：我附加了另一个磁盘，该磁盘在目录中（递归）有220万个文件，但是在XFS上。以下是一些比较结果：

                  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]与hdparm -T /dev/sdX和hdparm -t /dev/sdX。
[2] find mydir -print|wc -l引导后立即运行所花费的时间。
[3]在XFS磁盘上，这是使用沿着树走后不久find。在BTRFS磁盘上，这是旧的度量标准（我认为它与缓存的树无关）。

似乎是一个问题btrfs。

嗯，这仍然是Btrfs的问题，众所周知，与其他文件系统相比，删除许多小文件确实需要很长时间。

如果您不喜欢它，则可以等待，直到上游对其进行修复，或者继续使用其他性能更好的文件系统。

但是，您的主要错误是使用带有btrfs的古老内核（3.16，是的，发布时已经很古老了）。Btrfs是一个仍在繁重开发中的文件系统，因此您应始终使用最新，最强大的内核版本，以获取改进信息。如果您的发行版不做反向移植，您可以自己做，也可以避免。

Btrfs在3.19版内核中获得了许多性能改进-这是您应该在生产环境中使用的最低版本，您的3.16版内核显然没有反向移植。

还要记住，根据Chris Mason的说法，他确实认为Btrfs到目前为止很稳定，但尚未准备好生产。

我参加这个聚会有点晚了，但这是一个技巧，可以非常快地删除非常大的btrfs树：

1. 在同一btrfs文件系统上创建一个虚拟子卷。
2. 将要删除的顶级目录移动到该子卷中-如果您在同一btrfs文件系统上执行该操作，即使跨子卷，该操作也应该非常快。
3. 销毁子卷。

内核将开始在后台回收空间，因此您不会立即拥有可用空间，但是该过程应该比执行任何类型的用户土地删除都快得多。

您可以重命名目录，然后在后台进程中删除重命名的目录。这不会加快删除操作的速度。但是，这将允许程序在一边进行删除操作时继续使用空目录继续前进。

我不确定这是否可以在您的用例中使用。这取决于程序是否在磁盘空闲之前无法继续运行（即它将执行一些繁重的磁盘操作）。这取决于程序是否要用大量数据填充磁盘。