论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2008-08-19 16:40 |只看该作者 |倒序浏览

5可用积分

P570装的AIX 5.3，/bak目录下有几十个业务分别往各自的子目录下扔数以万计的数据文件（大小一般在1kB以内）。反正/bak目录在盘阵上，这个目录也很少用，偶尔进入一下知道列目录比较慢也没放在心上。
终于，有一天应用程序报错，不能往/bak/FPF目录mv数据了。

一检查吓了一跳，ls -ld /bak/FPF，目录大小已经达到了天文数字3307520000。

要命的是，这个目录虽然能够cd进去，但任何形式的ls都会提示
ls：. : Value too large to be stored in data type.

find 命令则提示
find: 0652-023 Cannot open file /bak/FPF.

rm -r 命令也提示
rm: 0653-602 Cannot read /bak/FPF.

tar 命令的报错更狠
tar: FPF.old: A file or directory in the path name does not exist.

$du FPF.old
du: FPF.old: Value too large to be stored in data type.

$fuser FPF.old
FPF.old:

粗粗估算了一下，这个子目录下面的文件数量在2千万以上，但/bak目录的%Iused还没到75%，df -g查看空间使用率也才70%，总容量400GB。用smitty查看这个jfs2类型的fs的容量，可是约1.6T。
看来，AIX下的jfs2文件系统，单个目录文件的最大容量莫过于此。

为了保证业务正常，临时把这个/bak/FPF更名成/bak/FPF.old，然后新建了一个/bak/FPF。

下定了决心，要把/bak下所有文件都按天归档打包，然后删除原文件。
其他子目录都差不多处理完了，跑了一周左右的时间。但这个/bak/FPF.old怎么也读不出其中的内容了，那几千万个小文件的空间无法回收。

请问各位大虾，应该怎么办？（不重做文件系统）

[ 本帖最后由 ncjh 于 2008-8-21 13:14 编辑 ]

最佳答案

xiaofeiwdh

查看完整内容

unix对目录文件的操作有一组单独的api，可能这组api实现的时候，没考虑一个目录能有这个大（比如实现这个函数内时，对目录文件中偏移使用了32位的int类型内部变量）。可以用ls -ld fpf.old看下目录文件大小是否超过2g了。如果真的是这个原因，那可能真的就只能找ibm了，aix里还有另外一组64位的api函数，可以访问大目录。如果他们提供这组64位命令，就可以把文件批量移出或者删除。验证方案，单独建个很小的文件系统（删除方便）， ...

文库|博客

xiaofeiwdh

白手起家

论坛徽章:: 0

2楼 [报告]

发表于 2008-08-19 16:40 |只看该作者

unix对目录文件的操作有一组单独的api，可能这组api实现的时候，没考虑一个目录能有这个大（比如实现这个函数内时，对目录文件中偏移使用了32位的int类型内部变量）。

可以用ls -ld fpf.old看下目录文件大小是否超过2g了。如果真的是这个原因，那可能真的就只能找ibm了，aix里还有另外一组64位的api函数，可以访问大目录。如果他们提供这组64位命令，就可以把文件批量移出或者删除。

验证方案，单独建个很小的文件系统（删除方便），用循环建一些文件名非常长的空文件，使目录达到2g，然后看访问是不是有问题。