头疼！AIX下的超大目录终于撑满了

ncjh

P570装的AIX 5.3，/bak目录下有几十个业务分别往各自的子目录下扔数以万计的数据文件（大小一般在1kB以内）。反正/bak目录在盘阵上，这个目录也很少用，偶尔进入一下知道列目录比较慢也没放在心上。\r\n终于，有一天应用程序报错，不能往/bak/FPF目录mv数据了。\r\n\r\n一检查吓了一跳，ls -ld /bak/FPF，目录大小已经达到了天文数字3307520000。\r\n\r\n要命的是，这个目录虽然能够cd进去，但任何形式的ls都会提示\r\nls：. : Value too large to be stored in data type.\r\n\r\nfind 命令则提示\r\nfind: 0652-023 Cannot open file /bak/FPF.\r\n\r\nrm -r 命令也提示\r\nrm: 0653-602 Cannot read /bak/FPF.\r\n\r\ntar 命令的报错更狠\r\ntar: FPF.old: A file or directory in the path name does not exist.\r\n\r\n$du FPF.old\r\ndu: FPF.old: Value too large to be stored in data type.\r\n\r\n$fuser FPF.old \r\nFPF.old: \r\n\r\n\r\n粗粗估算了一下，这个子目录下面的文件数量在2千万以上，但/bak目录的%Iused还没到75%，df -g查看空间使用率也才70%，总容量400GB。用smitty查看这个jfs2类型的fs的容量，可是约1.6T。\r\n看来，AIX下的jfs2文件系统，单个目录文件的最大容量莫过于此。\r\n\r\n为了保证业务正常，临时把这个/bak/FPF更名成/bak/FPF.old，然后新建了一个/bak/FPF。\r\n\r\n下定了决心，要把/bak下所有文件都按天归档打包，然后删除原文件。\r\n其他子目录都差不多处理完了，跑了一周左右的时间。但这个/bak/FPF.old怎么也读不出其中的内容了，那几千万个小文件的空间无法回收。\r\n\r\n请问各位大虾，应该怎么办？（不重做文件系统）\n\n[ 本帖最后由 ncjh 于 2008-8-21 13:14 编辑 ]

xiaofeiwdh

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

chalylau

要把/bak下所有文件都按天归档打包，然后删除原文件。\r\n

\r\n这种办法可行。

我老婆黑社会

你这个目录下文件有什么特点,比如有没有时间戳

chalylau

lsvg -l vgname\r\n\r\n看看你这个/bak所在lv的type正常吗？\r\n\r\n我以前遇见过type=“？”，而不是jfs2或jfs\n\n[ 本帖最后由 chalylau 于 2008-8-19 16:49 编辑 ]

我老婆黑社会

而且应用不能往里面写肯定是其他原因,INODE和容量都够,不可能写不进去的.IBM既然提供了这么大的INODE数量和容量,就肯定可以

tianyue01

它的inode用完了，df -k可确认。\r\n修改的ncargs值也许可能看ls.\r\nncargs属于sys0.

tianyue01

把ncargs修改为上限值看看。

meilixueshan

这只能分批删除了，看看文件有什么规律？

dooza

看样子，我也得加强日常维护工作的精细度。