如何“整理碎片” ext3 上的目录?
我正在运行一个守护进程,它分析目录中的文件,然后删除它们。如果守护进程由于某种原因没有运行,文件就会堆积在那里。今天该目录中有 90k 个文件。再次启动守护进程后,它处理了所有文件。
然而,目录仍然很大; “ls-dh”。返回大小为 5.6M。我如何对该目录进行“碎片整理”?我已经发现重命名该目录并创建一个具有相同名称和权限的新目录可以解决问题。然而,由于文件随时写入其中,似乎没有一种安全的方法来重命名目录并创建新目录,因为目标目录暂时不存在。
那么 a) 有没有一种方法/一个(shell)程序可以对 ext3 文件系统上的目录进行碎片整理?或者 b) 有没有办法在目录上创建锁,以便尝试写入文件会阻塞,直到重命名/创建完成为止?
I am running a daemon which analyses files in a directory and then deletes them. In case the daemon is not running for whatever reason, files get stacked there. Today I had 90k files in that directory. After starting the daemon again, it processed all the files.
However, the directory remains large; "ls -dh ." returns a size of 5.6M. How can I "defragment" that directory? I already figured out that renaming that directory, and creaing a new one with the same name and permissions solves the problem. However, as files get written in there at any time, there doesn't seem to be a safe way to rename the directory and create a new one as for a moment, the target directory does not exist.
So a) is there a way/a (shell) program which can defragment directories on an ext3 filesystem? or b) is there a way to create a lock on a directory so that trying to write files blocks until the rename/create has finished?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
“优化文件系统中的目录。此选项会导致 e2fsck 尝试优化所有目录,如果文件系统支持目录索引,则通过重新索引它们,或者通过对较小目录或使用传统线性目录的文件系统进行排序和压缩目录。” -- fsck.ext3 -D
当然,这不应该在已安装的文件系统上完成。
"Optimize directories in filesystem. This option causes e2fsck to try to optimize all directories, either by reindexing them if the filesystem supports directory indexing, or by sorting and compressing directories for smaller directories, or for filesystems using traditional linear directories." -- fsck.ext3 -D
Of course this should not be done on a mounted filesystem.
并不真正适用于 Ext3,但可能对其他文件系统的用户有用:
根据 https ://wiki.archlinux.org/index.php/Btrfs#Defragmentation,使用 Btrfs 显然可以对目录的元数据进行碎片整理:
btrfs filesystem defragment /< /code> 将对根文件夹的元数据进行碎片整理。这使用了 Btrfs 的在线碎片整理支持。
虽然Ext4确实支持在线碎片整理(使用
e4defrag
),但这似乎不适用于目录元数据(根据http://sourceforge.net/p/e2fsprogs/bugs/326/)。不过,我还没有尝试过这两种解决方案。
Not really applicable for Ext3, but maybe useful for users of other filesystems:
according to https://wiki.archlinux.org/index.php/Btrfs#Defragmentation, with Btrfs it is apparently possible to defragment the metadata of a directory:
btrfs filesystem defragment /
will defragment the metadata of the root folder. This uses the online defragmentation support of Btrfs.while Ext4 does support online defragmentation (with
e4defrag
), this doesn't seem to apply to directory metadata (according to http://sourceforge.net/p/e2fsprogs/bugs/326/).I haven't tried either of these solutions, though.
我不知道有什么方法可以从目录中回收可用空间。
5MB 的空间并不是很大,因此最简单的方法就是忽略它。如果此问题(文件在目录中堆积)定期发生,则只要目录再次填满,该空间就会被重复使用。
如果您迫切需要缩小目录的能力,这里有一个(丑陋的)黑客可能会起作用。
将目录替换为空目录的符号链接。如果此问题再次出现,您可以创建一个新的空目录,然后更改符号链接以指向新目录。更改符号链接应该是原子的,这样您就不会丢失任何传入的文件。然后您可以安全地清空并删除旧目录。
[编辑添加:事实证明这不起作用。正如 Bada 在评论中指出的那样,您不能按照我建议的方式自动更改符号链接。这让我保留了原来的观点。我熟悉的文件系统不提供回收目录块中可用空间的机制。]
I'm not aware of a way to reclaim free space from within a directory.
5MB isn't very much space, so it may be easiest to just ignore it. If this problem (files stacking up in the directory) occurs on a regular basis, then that space will be reused anytime the directory fills up again.
If you desperately need the ability to shrink the directory here's a (ugly) hack that might work.
Replace the directory with a symbolic link to an empty directory. If this problem reoccurs, you can create a new empty directory, and then change the symlink to point to the new directory. Changing the symlink should be atomic, so you won't loose any incoming files. Then you can safely empty and delete the old directory.
[Edited to add: It turns out that this does not work. As Bada points out in the comments you can't atomically change a symlink in the way I suggested. This leaves me with my original point. File systems I'm familiar with don't provide a mechanism to reclaim free space within directory blocks.]