几年来，存储系统从修订备份中收集了 17 亿个文件，并且已经有点满了。
所以我开始删除所有五年以上的文件。我假设大约有 17 亿（！！！）个文件，包含大约 90 TByte 的数据 - 我必须估计，因为即使只是一个 find 或 du 也需要几周甚至几个月的时间。后端（mdraid、ext4）本身实际上并不是太重要，因为无论如何我都想更改它。
我让 rm 删除文件一天，只删除了所有文件的 0.1% 左右。我估计以这种方式删除所有内容需要一到两年的时间。这样做时很可能会杀死一些驱动器。并不是我太担心，它是一个Hotswap RAID。
我一直在使用 ionice -c3 来确保仅在驱动器不忙时删除文件，以避免磁盘抖动，因为驱动器通常每天有 1-2 小时处于重负载状态。一个相当有趣的旁注是，当我第一次尝试运行 rm 时，数百万个硬链接将其内存使用量驱动到了 100GByte 左右，然后它进行了核心转储。因此，我将操作分成更小的部分，如果我只删除单个子目录，则可以工作文件，但仍然经常达到 20-30GByte 的峰值。
我的两个问题：
- 如何以不需要几年时间的方式删除该系统上的旧文件？
例如，我考虑手动编辑 Inode-Structures，这样文件就消失了，但空间没有归还，然后让 fsck 修复系统。
欢迎其他疯狂的想法。我总是可以通过制作 LVM 快照来恢复。
- 有哪些设置可以避免将来出现同样的问题？例如。使用不同的文件系统、不同的工具链，将元数据（索引节点、分配表等）放在 SSD 上 - 由于多种原因，数据本身需要保留在 HD 上。
如果没有人提出更好的主意，我将大大减少创建的修订数量和/或将所有超过一个月的内容 tar/xz 到外部 USB 驱动器。这并不酷，因为用户实际上喜欢能够访问修订版中的旧内容。
答案1
如果无法访问系统并且没有进行实验，就很难检查什么有效、什么有帮助、什么无用；但我的方式是这样的：
简而言之：不要删除不需要的文件，而是将mv它们删除到目录（这必须是一个快速操作），然后将此处的文件截断为 0 大小（以收回空间）；稍后您可以rm查看目录（以完全删除文件并取回索引节点）；这 3 个阶段中的每个阶段都可以根据系统负载并行或顺序完成。
详细信息：
创建一个目录 X。
在一个 shell 脚本 S1 中，mv大约 N=500 个不需要的文件放入 X/latest 并将其重命名为 X/X1，mv接下来的 N 个不需要的文件放入 X/latest 并将其重命名为 X/X2，mv接下来的 N 个不需要的文件文件放入 X/latest 并将其重命名为 X/X3 ....
在另一个 shell 脚本 S2 中，进入每个具有 N 个文件的目录 X/X1 、 X/X2 、 X/X3 并将文件截断为 0 大小并重命名目录 X/0X1、X/0X2、X/0X3 ....
在最后一个 shell 脚本 S3 中，rm目录 X/0X1 、 X/0X2 X/0X3 ....
在这里，目录命名确保每个 shell 脚本都是独立的，不会干扰其他脚本：S1 与 X/latest 一起工作； S2 与 X/X1、X/X2、X/X3 ... 配合使用； S3 可与 X/0X1、X/0X2、X/0X3 ... 配合使用：无冲突！
检查这 3 个阶段中的每一个是否可以根据系统负载并行或顺序完成。改变 N 并使用nice&ionice来sleep控制系统负载。
替代建议：
使用新位置来存储较新的修订版本，并让用户默认在此处查看。您甚至可以使用过去 1 个月生成的修订来填充此新位置 (cp或)。 万一，一个用户想要“所有修订”，则只能访问旧位置。 这将确保旧位置不会增长。然后，您可以轻松地轻松删除不需要的非常旧的修订版，而无需系统负载。mvrm
答案2
您可以使用较大的提交间隔（这相对节省但可能没有帮助）或使用nobarrier（应该有帮助）挂载分区，这在断电或内核崩溃方面极其危险。
异步 I/O 魔法可能会有所帮助，但我无法推荐任何工具。