背景
我有一个小的 logrotate 失误...... Logrotate 会因错误而旋转归档日志,从而导致我的/var/log/
. 当我发现有什么不对劲的时候,/var/log/
已经包含了几百万个文件......
我设法(在一些脱发和 find/sed/grep 魔术之后)删除了所有有问题的文件并修复了我的 logrotate 配置。并认为一切都很好......
问题
每当我ls
/du -hs
或以其他方式列出/var/log/
(现在包含 80mb 的档案/日志和最多几百个文件)的内容时,执行该操作的过程会挂起一两分钟。我确实相信这在某种程度上与 logrotate 事故有关,但我不确定,可能是其他原因。无论如何,我不知道从哪里开始调试或寻找解决方案。请帮助:3
其他信息
uname -a
Linux xxx 3.3.8-gentoo #18 SMP Sat Sep 21 22:44:40 CEST 2013 x86_64 Intel(R)
Core(TM)2 CPU 4400 @ 2.00GHz GenuineIntel GNU/Linux
cat /proc/meminfo
MemTotal: 2051552 kB
MemFree: 75612 kB
Buffers: 9016 kB
Cached: 1740608 kB
SwapCached: 0 kB
CFQ IO scheduler + SLUB allocator
我以为:一个目录中有多少文件太多了?(从网上下载数据)是相关的,但我没有留下文件了。
编辑
即使在调用之后问题仍然存在,init 1
所以我认为可以安全地假设除了 FS 之外没有其他进程可以归咎于。
解决方案(从接受的答案中应用)
init 1
mv /var/log /var/log1
mkdir /var/log
chmod --reference=/var/log1 /var/log
chown --reference=/var/log1 /var/log
tar -C /var/log1 -cvp . | tar -C /var/log -xvp
rm -rf /var/log1
init 5
目录只会增长,不会缩小。尝试将所有这些文件移出一个临时目录(如 log2),然后 rmdir 旧目录并将临时目录重命名为新的永久目录。
来自
man e2fsck
:换句话说,如果你有一个文件系统卷,你可以脱机,你可以简单地
e2fsck -Df <block_device>
在它上面运行,它会缩小所有目录。包括文件系统中的根目录,除非重新格式化卷,否则无法删除。在我的例子中,它成功地将卷上的根目录从 56MiB(曾经有超过 1M 的文件)缩小到大约 220KiB(大约 3-4K 的文件)。