转:Hp unix rm文件空间不释放问题解决
中午用户投诉说baan登陆出不了menu,报表打表没反应.
服务器为HP,UNIX, bdf查,/baanV full used. delete /baanV/bse/tmp的file,但未见空闲空间增大,怀疑为rm后,文件空间没释放,google查解决方法,见有:http://space.itpub.net/9134/viewspace-248017,转载如下:
Hp unix rm文件空间不释放问题解决
1 引言
很多人会遇到在操作系统上rm掉一个大的文件，以解决文件系统超标的问题，可是有的时侯文件删除掉了，而空间却未释放出来。论坛上也常常见这样贴子，为什么会这样，如何解决呢？本文只局限于Hp unix的操作系统。
2 rm掉文件空间不释放原因
原因其实很简单，主要是因为被删除的文件在删除的时侯还是进程在操作(打开、访问等)的缘故，rm只完成了在磁盘上文件实体的释放，而类似free list结构中相应的文件系统因进程的操作相应的inode并未释放。
3 解决的方法
这样的问题解决起来也很简单，找到操作的进程，kill掉就可以了，可是找到操作的进程恰恰是本问题的难点和关键。这样的问题也可以通过重启机器和nmount/mount文件系统这样的方式解决，但这样的方法我是不提倡的，小小的问题就重启机器，小题大做。
3.1 hp-unix操作系统
需要借助uli这个内部工具，后面会详细说。
3.2 linux及solaris
可以这样做:
a、下载一个lsof软件装上，google上可以搜到
b、找到正在用被删文件的进程
lsof | grep deleted
c、kill掉相应的进程空间就释放了
4 hp unix本问题的解决
4.1 问题重现
4.1.1 bdf一下/oracle文件系统
# bdf /oracle
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lv_oracle
8192000 5313813 2698313 66% /oracle
可见空余2698313kb
4.1.2 udump下有一文件占用了60多mb的空间
# pwd
/oracle/app/oracle/admin/yztest/udump
#
# ls -l yztest_ora_11026.trc
-rw-rw-rw- 1 root sys 62217530 Apr 23 10:36 yztest_ora_11026.trc
#
4.1.3 以more命令查看文件,保持这个操作不动
# more yztest_ora_11026.trc
4.1.4 另开一个窗口，删除文件，空间未释放
# rm yztest_ora_11026.trc
#
# ls -l yztest_ora_11026.trc
yztest_ora_11026.trc not found
#
# bdf /oracle
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lv_oracle
8192000 5313813 2698313 66% /oracle
可见/oracle文件系统的可用空间并未发生改变。
4.2 问题解决
4.2.1 安装uli工具
这个工具如果没有，可以向hp supporter要一个。
ftp到主机，注意用以二进制上传
# ls -l
total 960
-rw-rw-rw- 1 root sys 487379 Apr 23 10:22 uli.bin
解压缩，文件是自解压的
# sh ./uli.bin
Running install script. ./uli.install uli a 2
查看一下
# ls -l
total 5520
-rwxrwxrwx 2 222 users 1160136 Dec 13 2006 uli
-rwxrwxrwx 2 222 users 1160136 Dec 13 2006 uli-a-2
-rw-rw-rw- 1 root sys 487379 Apr 23 10:22 uli.bin
-rwxrwxrwx 1 222 users 536 Dec 13 2006 uli.install
执行uli.install
# ./uli.install uli a 2
#
查看一下uli的各个可用选项
# ./uli -h
4.2.2 执行uli，杀掉操作进程
# ./uli
libp4 (9.219): Opening /stand/vmunix /dev/kmem
Loading symbols from /stand/vmunix
Kernel TEXT pages not requested in crashconf
Will use an artificial mapping from a.out TEXT pages
Loading symbols from /stand/dlkm/mod.d/krm
Note: Consider P4_ELF_WARNING=2 to get more details
Note: No debug information for this module
Found 16 matching unlinked file table entries.
PID PPID COMMAND INODE DEVICE SIZE(bytes)
15128 13937 more 20177 /dev/vg00/lv_oracle 62217530
9619 1 GWTDOMAIN 4119 /dev/vg00/lvapp 131072
9618 1 GWADM 4119 /dev/vg00/lvapp 131072
9617 1 GWTDOMAIN 4110 /dev/vg00/lvapp 131072
9616 1 GWADM 4110 /dev/vg00/lvapp 131072
9611 1 GWTDOMAIN 3988 /dev/vg00/lvapp 131072
9610 1 GWADM 3988 /dev/vg00/lvapp 131072
9608 1 GWTDOMAIN 3884 /dev/vg00/lvapp 131072
9607 1 GWADM 3884 /dev/vg00/lvapp 131072
9604 1 GWTDOMAIN 3856 /dev/vg00/lvapp 131072
9603 1 GWADM 3856 /dev/vg00/lvapp 131072
2775 1 swagentd 3936 /dev/vg00/lvol7 141
2209 1 java 28778 /dev/vg00/lvol7 13
2209 1 java 960 /dev/vg00/lvol7 3215
2209 1 java 960 /dev/vg00/lvol7 3215
2209 1 java 10180 /dev/vg00/lvol7 3215
可见15128进程执行了more操作，影响了空间的释放
杀掉15128
# kill 15128
#
4.2.3 再查看一下/oracle的空间
# bdf /oracle
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lv_oracle
8192000 5253045 2755283 66% /oracle
可见，可用空间已经由原来的2698313kb升为2755283kb。
5 结篇
解决问题的方法是很多的，对于复杂的问题也可能有很简便的解决的方法，所以最好在用重启机器这样方法之前偿试一下，看是否有更好的更方便的方法。