在AIX服务器上，用“df -k" 查看/home目录使用99%（大约使用了32M），但到home目录下，用du -sk 去查看文件占用空间情况，发现应该只使用了491k，那剩余的约31.5M空间被那些文件占用了？如何去查找这些文件？
server1:/home>df -k
Filesystem 1024-blocks Free %Used Iused %Iused Mounted on
/dev/hd4 65536 30688 54% 2138 7% /
/dev/hd3 753664 478200 37% 6417 4% /tmp
/dev/hd1 32768 608 99% 70 1% /home
server1:/home>du -sk
491 .
server1:/home>du -sk *
1 guest
1 lost+found
433 mqm
57 netinst
jnwwww 回复于：2007-05-22 11:37:03
fcsk
jnwwww 回复于：2007-05-22 11:39:34
....................
fsck
thesix 回复于：2007-05-22 11:45:52
有好几种可能的办法，但不是一两句话能说清楚的。不知道你用的是哪个版本的AIX?
security1024 回复于：2007-05-22 15:21:50
AIX版本是4.3,
难道是文件系统不一致性引起的？需要fsck?
unixasdfg 回复于：2007-05-22 15:26:27
引用：原帖由 security1024 于 2007-5-22 10:34 发表
在AIX服务器上，用“df -k" 查看/home目录使用99%（大约使用了32M），但到home目录下，用du -sk 去查看文件占用空间情况，发现应该只使用了491k，那剩余的约31.5M空间被那些文件占用了？如何去查找这些文件？ ...
要fuser命令对home文件系统找一下,看一下是什么文件占了空间.
security1024 回复于：2007-05-22 15:33:06
fuser 不是用于查看那个用户在使用文件系统的吗？ 如果可以查看文件的话,能写下具体的命令吗？谢谢
unixasdfg 回复于：2007-05-22 15:46:22
引用：原帖由 security1024 于 2007-5-22 15:33 发表
fuser 不是用于查看那个用户在使用文件系统的吗？ 如果可以查看文件的话,能写下具体的命令吗？谢谢
fuser -cux /home
unixasdfg 回复于：2007-05-22 15:51:32
引用：原帖由 security1024 于 2007-5-22 15:33 发表
fuser 不是用于查看那个用户在使用文件系统的吗？ 如果可以查看文件的话,能写下具体的命令吗？谢谢
用fuser查出什么东西占了空间,看是否你有用的,然后再删除.
security1024 回复于：2007-05-22 15:54:57
看完man fuser还是没明白这个结果如何能看到那31.5M被那些文件占用了，帮忙看看？谢谢
server1:/home>fuser -cux /home
/home: 22672c(root) 22880c(root) 31620c(user01) 32482c(user01) 33040c(user01) 40280c(root)
unixasdfg 回复于：2007-05-22 16:05:32
引用：原帖由 security1024 于 2007-5-22 15:54 发表
看完man fuser还是没明白这个结果如何能看到那31.5M被那些文件占用了，帮忙看看？谢谢
server1:/home>fuser -cux /home
/home: 22672c(root) 22880c(root) 31620c(user01) 32482c(user01) 33040c ...
那你用du -a /home|more看一下什么文件占了空间.然后再删除.
security1024 回复于：2007-05-22 16:14:06
结果和“du -sk"查到的差不多，应该没有什么大的隐含文件。 为什么用“df -k看到文件系统为32M，使用率为99%，而"du -sk "就是查不到30M的空间被谁占用了？
server1:/home>du -a /home |more
1 /home/lost+found
1 /home/guest
1 /home/user02/.profile
19 /home/user02/bin/instsrv
25 /home/user02/bin/instsrv.c
45 /home/user02/bin
1 /home/user02/db/choices
4 /home/user02/db/class.sample
5 /home/user02/db/default.client
9 /home/user02/db/sample.client
20 /home/user02/db
3 /home/user02/scripts/clientdb
2 /home/user02/scripts/curdate
5 /home/user02/scripts/dbextract
2 /home/user02/scripts/defaults
21 /home/user02/scripts/getdb
3 /home/user02/scripts/netcat
3 /home/user02/scripts/sendfile
3 /home/user02/scripts/sendfssz
3 /home/user02/scripts/showchoices
46 /home/user02/scripts
113 /home/user02
1 /home/user01/.profile
6 /home/user01/.sh_history
80 /home/user01/ms03/channel.c
35 /home/user01/ms03/mqutils.c
15 /home/user01/ms03/namelist.c
22 /home/user01/ms03/process.c
36 /home/user01/ms03/qmgr.c
54 /home/user01/ms03/queue.c
112 /home/user01/ms03/saveqmgr.c
37 /home/user01/ms03/saveqmgr.h
2 /home/user01/ms03/makefile.aix
27 /home/user01/ms03/saveqmgr.o
8 /home/user01/ms03/namelist.o
27 /home/user01/ms03/channel.o
17 /home/user01/ms03/mqutils.o
11 /home/user01/ms03/process.o
17 /home/user01/ms03/qmgr.o
23 /home/user01/ms03/queue.o
128 /home/user01/ms03/saveqmgr
45 /home/user01/ms03/DMZ_QMGR.TST
32 /home/user01/ms03/SEN.TST
32 /home/user01/ms03/SEN_QMGR.TST
18 /home/user01/ms03/SEN2.TST
779 /home/user01/ms03
1 /home/user01/smit.log
0 /home/user01/smit.script
72 /home/user01/SEN2_20041109.tst
3 /home/user01/petDMZQMGR_20060628.tst
3 /home/user01/petSENQMGR_20060628.tst
866 /home/user01
982 /home
unixasdfg 回复于：2007-05-22 16:16:13
引用：原帖由 security1024 于 2007-5-22 15:54 发表
看完man fuser还是没明白这个结果如何能看到那31.5M被那些文件占用了，帮忙看看？谢谢
server1:/home>fuser -cux /home
/home: 22672c(root) 22880c(root) 31620c(user01) 32482c(user01) 33040c ...
那你用du -a /home|more查一下,看什么文件占了空间,然后再删除.
thesix 回复于：2007-05-22 16:50:32
引用：原帖由 security1024 于 2007-5-22 15:21 发表
AIX版本是4.3,
4.3 太老了，我这也没法试。
前面fuser 显示的是正在使用该文件系统文件的进程号和用户名，如果你不在乎把这些进程杀掉的话就简单了：确认杀掉这些进程，再看看文件系统空间是否被释放了。
要具体找出哪个文件在占用空间就麻烦一点。
先试一下有没有kdb (as root)
# kdb
如果看到kdb提示符，试一下这个命令：
(0)> inode | grep CNOLINK
有没有返回？有没有报错？贴出来。
(0)> q
退出kdb.
security1024 回复于：2007-05-22 16:57:33
谢谢先！这些进程真的不可以停掉的（生产机），你是说有用户使用该文件系统的话，会占用该文件系统的空间吗？
下面是kdb输出：
server1:/home>kdb
Preserving 618261 bytes of symbol table
First symbol __mulh
KERNEXT FUNCTION NAME CACHE (90112 bytes) allocated
KERNEXT COMMANDS SPACE (4096 bytes) allocated
START END <name>
0000000000003500 0000000001427120 _system_configuration+000020
000000002FF3B400 000000002FF7E428 __ublock+000000
000000002FF22FF4 000000002FF22FF8 environ+000000
000000002FF22FF8 000000002FF22FFC errno+000000
00000000E0000000 00000000F0000000 lkwseg+10000000
PFT:
id....................0007
raddr.....0000000002000000 eaddr.....0000000002000000
size..............02000000 align.............02000000
valid..1 ros....0 holes..0 io.....0 seg....1 wimg...2
PVT:
id....................0008
raddr.....0000000000291000 eaddr.....0000000000291000
size..............00200000 align.............00001000
valid..1 ros....0 holes..0 io.....0 seg....1 wimg...2
(0)> inode | grep CNOLINK
Expected symbol, address or slot_number.
(0)> q
server1:/hom
chinadns 回复于：2007-05-22 19:51:14
文件系统元数据
thesix 回复于：2007-05-22 23:10:11
（今天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'.
这个不行还有其他办法，但我写这些真是够累的，很花时间啊。:lol::lol:
security1024 回复于：2007-05-23 10:36:56
哈哈，辛苦辛苦，如果到上海我请你吃饭好了：）
按照你说的，有点理解了。把结果贴出来，请辛苦一下，帮忙看看
另外一个小问题： 那里可以找到相关的资料讲“kde“的？
DEV NUMBER CNT GNODE IPMNT TYPE FLAGS
169903 inodes+3A54CE0 000A0007 129 1 16A54CF0 16F18E70 REG CMNOLINK
176939 inodes+3CBF340 000A0008 2057 1 16CBF350 143985E8 REG CMNOLINK
157917 inodes+3637590 000A0008 2064 1 166375A0 143985E8 REG CMNOLINK
125544 inodes+2B1A108 000A0009 2095 1 15B1A118 16AC1B38 REG CHG UPD CMNOLINK
157229 inodes+35FAE10 000A0009 2098 1 165FAE20 16AC1B38 REG CHG UPD CMNOLINK
177562 inodes+3CF5F58 000A0006 4174 1 16CF5F68 1572A390 SOCK CMNOLINK
107856 inodes+2507748 000A0006 4190 1 15507758 1572A390 SOCK CMNOLINK
96574 inodes+437CEF8 000A0006 4191 1 1737CF08 1572A390 SOCK CMNOLINK
35051 inodes +C08940 000A0009 22553 1 13C08950 16AC1B38 REG CMNOLINK
28714 inodes +9DB9D8 000A0009 22552 1 139DB9E8 16AC1B38 REG CMNOLINK
123768 inodes+2A7DF88 000A0009 22555 1 15A7DF98 16AC1B38 REG CMNOLINK
136442 inodes+2ED7E58 000A0009 22557 1 15ED7E68 16AC1B38 REG CMNOLINK
130105 inodes+2CAAEF0 000A0009 22556 1 15CAAF00 16AC1B38 REG CMNOLINK
149116 inodes+3331D28 000A0009 22559 1 16331D38 16AC1B38 REG CMNOLINK
142779 inodes+3104DC0 000A0009 22558 1 16104DD0 16AC1B38 REG CMNOLINK
167048 inodes+3959E08 000A0009 8201 1 16959E18 16AC1B38 REG CMNOLINK
28720 inodes +9DC248 000A0009 8200 1 139DC258 16AC1B38 REG CMNOLINK
41394 inodes +E36118 000A0009 8203 1 13E36128 16AC1B38 REG CMNOLINK
5057 inodes +C091B0 000A0009 8202 1 13C091C0 16AC1B38 REG CMNOLINK
187144 inodes+4040208 000A0009 8204 1 17040218 16AC1B38 REG CMNOLINK
2288 inodes +0C9048 000A0009 8207 1 130C9058 16AC1B38 REG CMNOLINK
198733 inodes+443AB10 000A0009 8206 1 1743AB20 16AC1B38 REG CMNOLINK
141700 inodes+30A6068 000A0009 8197 1 160A6078 16AC1B38 REG CMNOLINK
135363 inodes+2E79100 000A0009 8196 1 15E79110 16AC1B38 REG CMNOLINK
148037 inodes+32D2FD0 000A0009 8198 1 162D2FE0 16AC1B38 REG CMNOLINK
22384 inodes +7AF448 000A0009 8216 1 137AF458 16AC1B38 REG CMNOLINK
41395 inodes +E36280 000A0009 8219 1 13E36290 16AC1B38 REG CMNOLINK
35058 inodes +C09318 000A0009 8218 1 13C09328 16AC1B38 REG CMNOLINK
199818 inodes+449A0D8 000A0009 8208 1 1749A0E8 16AC1B38 REG CMNOLINK
21299 inodes +74FE80 000A0009 8210 1 1374FE90 16AC1B38 REG CMNOLINK
16047 inodes +5824E0 000A0009 8215 1 135824F0 16AC1B38 REG CMNOLINK
thesix 回复于：2007-05-23 11:20:49
引用：原帖由 security1024 于 2007-5-23 10:36 发表
[font=Courier New]
176939 inodes+3CBF340 000A0008 2057 1 16CBF350 143985E8 REG CMNOLINK
157917 inodes+3637590 000A0008 2064 1 166375A0 143985E8 REG CMNOLINK
[/font]
/home 应该是 /dev/hd1 000A0008 (major number 10, minor number 8).
你可以看一下以上两个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/doc_link/en_US/a_doc_lib/cmds/aixcmds3/kdb.htm
上面是5.1 kdb的文档。4.3.3文档不知道在哪还有。kdb的功能在每个AIX版本中都有扩充。
security1024 回复于：2007-05-23 11:53:54
非常感谢！
我还是有三个小问题：）：
1)如何确定/home 应该是 /dev/hd1 000A0008 ？而不是000A0006 或别的？
2)如果某个进程在使用一个文件，该文件可以被删除吗？
3)像现在的情况，是否只有等这些进程结束或被Kill后，空间才能释放出来？
下面是相关输出:
(0)> inode inodes+3CBF340
size 000000000114FEEBgets 00000000
(0)> inode inodes+3637590
size 0000000000C7FF38gets 00000000
下面的命令没有返回
# find /home -xdev -inum 2057
# find /home -xdev -inum 2064
chinadns 回复于：2007-05-23 21:23:55
1） major number，minor number 应该是000A0008十六进制
2）可以
3）是
咱也学习学习
thesix 回复于：2007-05-23 22:57:35
(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#）。
security1024 回复于：2007-05-24 09:57:32
恭喜恭喜，找到了这31M ：）
我查过设备的major number & minor number。都是对的！
正如您说的，我如何将那两个inode和fuser报告的进程对应起来呢？再辛苦一下？到上海后请你喝酒：）
jtw 回复于：2007-05-24 15:42:08
其实不用那么麻烦，一条命令就可以搞定：
fuser -dV /home
会列出已经删除的文件的i-node，文件大小，使用此文件的进程号。
kill掉这些进程，就会释放删除文件的空间。
security1024 回复于：2007-05-24 16:07:49
jtw说的对的，结果如下，非常感谢thesix 帮我找到了问题所在并使我接触到KDB，感谢jtw 提供的简洁方
法来解决这个问题。
server1:/dev>fuser -dV /home
/home:
inode=2057 size=18153195 fd=6 22672
inode=2064 size=13107000 fd=6 40280
server1/dev>ps -ef | grep 22672
root 22672 15794 0 Aug 30 - 0:00 ftpd
root 39296 36936 1 16:01:06 pts/1 0:00 grep 22672
server1:/dev>ps -ef | grep 40280
root 34902 36936 0 16:01:19 pts/1 0:00 grep 40280
root 40280 15794 0 Aug 30 - 0:00 ftpd
yanbing 回复于：2008-01-25 13:46:38
绝对强帖，绝对精华，刚看到，罪过罪过！
|
