查找占用空间的文件

thesix

有好几种可能的办法，但不是一两句话能说清楚的。不知道你用的是哪个版本的AIX?

thesix

原帖由 security1024 于 2007-5-22 15:21 发表
AIX版本是4.3,

4.3 太老了，我这也没法试。

前面fuser 显示的是正在使用该文件系统文件的进程号和用户名，如果你不在乎把这些进程杀掉的话就简单了：确认杀掉这些进程，再看看文件系统空间是否被释放了。

要具体找出哪个文件在占用空间就麻烦一点。
先试一下有没有kdb (as root)

# kdb

如果看到kdb提示符，试一下这个命令：

(0)> inode | grep CNOLINK

有没有返回？有没有报错？贴出来。

(0)> q
退出kdb.

thesix

（今天cu好像处问题了，发表几次都不成功。）

原帖由 security1024 于 2007-5-22 16:57 发表
谢谢先！这些进程真的不可以停掉的（生产机），你是说有用户使用该文件系统的话，会占用该文件系统的空间吗？

通常df 和du 不一致的原因有两条：
1. df 报告的使用量包括 filesystem metadata， 这部分是du 看不到的。

   如果df/du差别相对文件系统本身大小不大的话，不能排除这个原因。

2. 如果一个进程正在使用某个文件 (file reference count >0)，而该文件又从目录中被“删除”了( file disk link count = 0)，那么这个文件所占用的空间在df中会体现出来，因为它们还没被释放，但du找不到这个文件，从而不能报出它占用的空间。
根本的区别在于：df看的是文件系统总的空间分配量（不是读每个文件的大小），而du是一个文件(disk inode)一个文件地去读，然后累加。

只有当使用“已删除”文件的那个进程把文件关闭（比如进程本身退出）时，那个文件所持有的空间才会被释放到文件系统的可用空间中去，才能在df中体现出来。

下面是kdb输出：
(0)> inode | grep CNOLINK
Expected symbol, address or slot_number.
(0)> q

想起来了，4.3的kdb 不支持 "grep".
如果单独用 "inode" 呢？

(0)> inode

输出可能很长，想办法存到一个文件中去，再 'grep CNOLINK'.

这个不行还有其他办法，但我写这些真是够累的，很花时间啊。

thesix

原帖由 security1024 于 2007-5-23 10:36 发表

176939 inodes+3CBF340 000A0008       2057   1 16CBF350 143985E8 REG  CMNOLINK
157917 inodes+3637590 000A0008       2064   1 166375A0 143985E8 REG  CMNOLINK

/home 应该是 /dev/hd1 000A0008 (major number 10, minor number .

你可以看一下以上两个inode的大小：

(0)> inode inodes+3CBF340
(0)> inode inodes+3637590
在输出中找 "size"。

它们应该已经被“删除”了。
# find /home -xdev -inum 2057
# find /home -xdev -inum 2064
应该没有返回。

http://publibn.boulder.ibm.com/d ... ds/aixcmds3/kdb.htm
上面是5.1 kdb的文档。4.3.3文档不知道在哪还有。kdb的功能在每个AIX版本中都有扩充。

thesix

(0)> hcal 114FEEB+00C7FF38
Value hexa: 01DCFE23          Value decimal: 31260195

正好差不多是31MB！庆祝一下

1) 先找到文件系统对应的LV, 然后 'ls /dev' 看相应LV的major number & minor number.
    我看了一下我的机器中/home (/dev/hd1) 是10/8，因为rootvg中maj/min相对固定，所以我猜你的也是。
2) 可以。所谓的 Open/Reference Count 和 Disk Link Count 是相对独立的。
3) 是。我们还没把那两个inode和fuser报告的进程对应起来，在4.3.3中作又需要几个kdb子命令（5.3中可以用procfiles 命令列出进程打开的file descriptor，包括inode#）。