![巨大的目录,不是里面的文件,而是目录本身](https://linux22.com/image/521226/%E5%B7%A8%E5%A4%A7%E7%9A%84%E7%9B%AE%E5%BD%95%EF%BC%8C%E4%B8%8D%E6%98%AF%E9%87%8C%E9%9D%A2%E7%9A%84%E6%96%87%E4%BB%B6%EF%BC%8C%E8%80%8C%E6%98%AF%E7%9B%AE%E5%BD%95%E6%9C%AC%E8%BA%AB.png)
在过去的 15 个小时里,我一直在尝试从 centos 服务器中删除一个目录rm -Rf /root/FFDC
,但遇到了很大困难。我无法列出目录,因为它会挂起系统(文件太多?),但我能看到的是目录大小不是通常的 4096 字节,而是 488MB!
[root@IS-11034 ~]# ls -al
total 11760008
drwxr-x--- 31 root root 4096 Aug 10 18:28 .
drwxr-xr-x 25 root root 4096 Aug 10 16:50 ..
drwxr-xr-x 2 root root 488701952 Aug 11 12:20 FFDC
我检查了 inode,一切似乎都很好。我检查了 top,rm
15 小时后 CPU 的使用率仍为 0.7%。文件系统类型为 ext3。
除了备份和格式化,我现在不知道该怎么办。
答案1
很ls -1f /root/FFDC
慢吗?使用 -1f 时输出将不会被排序,文件详细信息将被忽略。
如果上面的 ls 运行得很快,那么类似这样的代码find /root/FFDC | xargs rm -vf
可能更快?正常情况下rm -rf
,可能会执行所有类型的递归,但find
可能可以跳过这些递归。或者不会。
你的文件系统是否挂载了同步选项?如果是,那么写入/删除性能会比使用异步如果有疑问,您可以尝试mount -o remount,async /
(或者mount -o remount,async /root
如果这对您来说是一个单独的文件系统)。
答案2
您是否考虑过卸载文件系统,然后运行 e2fsck 来检查文件系统是否有错误?我会在备份、格式化、恢复之前尝试这个。
答案3
在文件系统上运行 fsck 可以修复此问题。通常情况下,当目录曾经包含许多文件但现在不再包含时,就会发生此问题。目录大小非常大,性能会受到影响。
答案4
我不确定fsck(8)
是否会重新组织目录,您可以尝试标志-D
(如中所述e2fsck(8)
)。如果没有,并且如果该目录中确实没有数百万个文件,也许类似下面的内容会给出一个合理大小的目录:
cd /root mv FFDC FFCD-old mkdir FFCD # 调整 FFDC 的权限 mv FFDC-old/* FFDC # 检查/移动 FFDC-old 中的任何 .xxx 文件/目录 rmdir FFCD-old
至少有几个 bash 版本会得到错误的和包含的 glob ,.a[^.]*
否则你可以尝试下一步.
..
mv FFDC-old/.* FFDC
文件系统(如 ext3/ext4)本质上将目录处理为不可移动节点的链接列表,其中包含文件名 + inode 编号的空间,当文件取消链接时,名称的空间将被释放(并且应该与可用的邻居条目合并,如果有的话)。因此,这样一个只有少量文件的巨大目录能可以创建,但这并不容易。也许创建指向相同几个文件的数百万个硬链接?创建/删除数百万个带有精心设计的名称的链接?无论发生了什么,都值得调查;是恶作剧,还是某种文件系统故障,......?