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

kv3000beta

能touch 一个文件吗？如果不能就很有可能是没有连续的block造成的，虽然INODE和磁盘空间都未满。
方案一
The JFS2 filesystem performs many operations to gain greater performance when reading and writing to files and directories within it. One such operation is that when a block of data is allocated in the filesystem, JFS2 attempts to pre-allocate the next contiguous block as well. This is done to speed up performance of file creation, as in general use a file will consist of more than one block of data, and is usually more performant if in a contiguous area of the filesystem.

However, in a filesystem that is very nearly full, or very fragmented, there may not be enough contiguous space to allocate two such contiguous blocks (or extents in JFS2) of 16Kb in size, and the file creation may fail.

This can be illustrated with a simple 'touch' command, to create a new zero-length file. This will attempt to allocate a pair of 16Kb extents of data in the filesystem:

$ touch myfile
touch: cannot create

If "df" shows the filesystem is approaching being full, or even as little as 50-60% full in a heavily fragmented filesystem, then it may be that you are encountering this issue. In some cases running the defragfs command to defragment the filesystem may give you enough contiguous space to allow the creation of new files. However defragfs may not help if it cannot defragment the filesystem enough, or it truly is very full.


If this is on an NFS, JFS, or other filesystem that is NOT JFS2, then this is NOT your issue and enabling Variable Inode Extents will not help.


Variable Inode Extents were a feature added with APARs:

APAR IY68589 for AIX 5.2 - included in 5200-07

APAR IY68174 for AIX 5.3 - included in 5300-03


By default the filesystem needs contiguous 16Kb extents. Using Variable Inode Extents allows JFS2 to allocate a smaller extent if 16Kb is too large.

To enable Variable Inode Extents, unmount the filesystem and use chfs with the following option, from the man page:


   -a vix={yes|no}
       Specifies whether the file system can allocate inode
       extents smaller than the default of 16K if there are no
       contiguous 16K extents free in the file system. After a
       file system is enabled for small free extents, it cannot
       be accessed on earlier versions of AIX and the marking
       cannot be removed.

        yes
            File system can allocate variable length inode
            extents.
        no
            File system must use default size of 16 KB for
            inode extents. This has no effect if the file
            system already contains variable length inode
            extents.

So if there is a filesystem /myfs you wish to enable VIX on, follow these steps:

# umount /myfs
# chfs -a vix=yes /myfs
# lsfs -q /myfs

# lsfs -q /myfs
Name            Nodename   Mount Pt               VFS   Size    Options    Auto Accounting
/dev/fslv01     --         /myfs                  jfs2  131072  rw         no   no
  (lv size: 131072, fs size: 131072, block size: 4096, sparse files: yes, inline log: no, inline log size: 0, EAformat: v1, Quota: no, DMAPI: no, VIX: yes)

# mount /myfs


Note there may be a performance degradation of writes or file creation to the JFS2 filesystem after enabling VIX, as you are disabling or limiting a previous performance characteristic of the JFS2 filesystem.

方案二
扩大该文件系统或者用defragfs命令，治标不治本，不删早晚还会满

方案三（我碰到大量小文件时解决方法）
/bak/FPF下面不是还有一些目录吗？前提是你知道该文件系统下有哪些目录。假设为目录A，进入到/bak/FPF/A下面，用ls命令能否列出文件。如果能，另建文件系统，将A目录下内容拷贝出来，然后删掉A目录下内容，只拷贝A目录的，如成功，则其他目录也如此。如果进入A目录不能用ls列出文件，除非你知道A下还有哪些目录，否则该方案无效。

dongli

关注、学习中

qzdmail

把这个目录cp到别的机器在LS呢？

kougq168

昨天我们培训老师就提到这个问题，经过大家讨论，还是没有好的解决方法，关注中！

ncjh

非常抱歉，这段时间太忙没有上公网。

问题已经明确了， http://www-01.ibm.com/support/docview.wss?uid=isg1IY76976
就是因为相关标准命令只支持32bit长度。

咨询了IBM公司，需要打个系统补丁才行。涉及reboot，只有放到以后再说了。

谢谢各位关心

ncjh

原帖由 kv3000beta 于 2008-9-3 21:21 发表
能touch 一个文件吗？如果不能就很有可能是没有连续的block造成的，虽然INODE和磁盘空间都未满。
方案一
The JFS2 filesystem performs many operations to gain greater performance when reading and writi ...

且不论方法是否可行，这位兄弟真是太让我感动了。谢谢！谢谢！谢谢！～～～

ncjh

原帖由 tyrone.dev 于 2008-8-21 19:56 发表
试试

1. perl_64bit -e 'use File::path ; rmtree( "directory" )'

复制代码

这位大侠的思路很有价值。哪天我有空了来试试

但是对于海量文件的读取，还要仔细斟酌一下ｐｅｒｌ编程。直接remove是最后的一招。

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

ncjh

原帖由 xiaofeiwdh 于 2008-8-22 16:40 发表
unix对目录文件的操作有一组单独的api，可能这组api实现的时候，没考虑一个目录能有这个大（比如实现这个函数内时，对目录文件中偏移使用了32位的int类型内部变量）。

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

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

不用验证了，您说得非常正确。

64bit的命令组，得打一个系统补丁才行。

zongyongchun

没有查到官方文档说单个目录下最大支持多少个文件，我想用touch 模拟一下，但是取多少个文件，才能触发呢？真的是那个BUG所致吗？

LZ系统的版本是多少？

wlio_x

学习了.