转: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 结篇

解决问题的方法是很多的,对于复杂的问题也可能有很简便的解决的方法,所以最好在用重启机器这样方法之前偿试一下,看是否有更好的更方便的方法。

猜你喜欢

转载自peter19.iteye.com/blog/1913021