为什么删除文件后磁盘空间还是不变

解决方法

 

首先我们获得一个已经被删除但是仍然被应用程序占用的文件列表：用root用户；

#lsof|grep deleted

进程名   PID       USER    FD   文件类型    大小(字节)  索引节点                          文件名  [(状态)]

ora      25575     data     33u      REG      65,65    4294983680   31014933 /oradata/DATAPRE/UNDOTBS009.dbf (deleted)

从lsof的输出中，我们可以发现pid为25575的进程持有着以文件描述号（fd）为33打开的文件/oradata/DATAPRE/UNDOTBS009.dbf。

在我们找到了这个文件之后可以通过结束进程的方式来释放被占用的空间。

#kill -9  25575

或者

#cd /root/.Trash/

#rm -rif * 

 

 

linux删除文件后没有释放空间

今天发现一台服务器的home空间满了，于是要清空无用的文件，当我删除文件后，发现可用空间没有变化

os：centos4.7

 

现象：

发现当前磁盘空间使用情况：

[root@ticketb ~]# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda1 981M 203M 729M 22% /

none 16G 0 16G 0% /dev/shm

/dev/sda9 2.9G 37M 2.7G 2% /tmp

/dev/sda7 4.9G 1.9G 2.7G 42% /usr

/dev/sda8 2.9G 145M 2.6G 6% /var

/dev/mapper/vghome-lvhome

20G 19G 11M 100% /home

/dev/mapper/vgoradata-lvoradata

144G 48G 90G 35% /u01/oradata

/dev/mapper/vgbackup-lvbackup

193G 7.8G 175G 5% /u01/backup

 

通过下面的命令找到无用的文件，然后删除

 

[root@ticketb ~]# find /home/oracle/admin/dbticb/udump/ -name "dbticb_*.trc" -mtime +50 | xargs rm -rf

然后在查看磁盘空间使用情况，发现没有/home空间没有变化

[root@ticketb ~]# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda1 981M 203M 729M 22% /

none 16G 0 16G 0% /dev/shm

/dev/sda9 2.9G 37M 2.7G 2% /tmp

/dev/sda7 4.9G 1.9G 2.7G 42% /usr

/dev/sda8 2.9G 145M 2.6G 6% /var

/dev/mapper/vghome-lvhome

20G 19G 11M 100% /home

/dev/mapper/vgoradata-lvoradata

144G 48G 90G 35% /u01/oradata

/dev/mapper/vgbackup-lvbackup

193G 7.8G 175G 5% /u01/backup

这个郁闷啊，明明删除文件了，怎么空间没有被释放啊，rm命令应该是直接删除啊，在查看下/home下还有什么占用空间

[root@ticketb ~]# du -h --max-depth=1 /home

16K /home/lost+found

2.6G /home/oracle

2.6G /home

可这里显示空间已经释放了啊，于是google下，

未释放磁盘空间原因：

在Linux或者Unix系统中，通过rm或者文件管理器删除文件将会从文件系统的目录结构上解除链接(unlink).然而如果文件是被

打开的（有一个进程正在使用），那么进程将仍然可以读取该文件，磁盘空间也一直被占用。而我删除的是oracle的告警log文件

删除的时候文件应该正在被使用

解决方法

首先获得一个已经被删除但是仍然被应用程序占用的文件列表，如下所示：

 

[root@ticketb ~]# lsof |grep deleted

oracle 12639 oracle 5w REG 253,0 648 215907 /home/oracle/admin/dbticb/udump/dbticb_ora_12637.trc (deleted)

oracle 12639 oracle 6w REG 253,0 16749822091 215748 /home/oracle/admin/dbticb/bdump/alert_dbticb.log (deleted)

oracle 12639 oracle 7u REG 253,0 0 36282 /home/oracle/oracle/product/10.2.0/db_1/dbs/lkinstdbticb (deleted)

oracle 12639 oracle 8w REG 253,0 16749822091 215748 /home/oracle/admin/dbticb/bdump/alert_dbticb.log (deleted)

oracle 12641 oracle 5w REG 253,0 648 215907 /home/oracle/admin/dbticb/udump/dbticb_ora_12637.trc (deleted)

oracle 12641 oracle 6w REG 253,0 16749822091 215748 /home/oracle/admin/dbticb/bdump/alert_dbticb.log (deleted)

。

。

。

oracle 23492 oracle 6w REG 253,0 16749822091 215748 /home/oracle/admin/dbticb/bdump/alert_dbticb.log (deleted)

oracle 23492 oracle 7u REG 253,0 0 36282 /home/oracle/oracle/product/10.2.0/db_1/dbs/lkinstdbticb (deleted)

oracle 23492 oracle 8w REG 253,0 16749822091 215748 /home/oracle/admin/dbticb/bdump/alert_dbticb.log (deleted)

oracle 23494 oracle 10u REG 253,0 0 36307 /home/oracle/oracle/product/10.2.0/db_1/dbs/lkinstrmandb (deleted)

 

从输出结果可以看到/home/oracle/admin/dbticb/bdump/alert_dbticb.log还被使用，未被释放空间

如何让进程释放呢？

一种方法是kill掉相应的进程，或者停掉使用这个文件的应用，让os自动回收磁盘空间

我这个环境有很多进程在使用的这个文件，停掉进程有点麻烦，再有就是风险很大

当linux打开一个文件的时候,Linux内核会为每一个进程在/proc/ 『/proc/nnnn/fd/目录（nnnn为pid）』建立一个以其pid

为名的目录用来保存进程的相关信息，而其子目录fd保存的是该进程打开的所有文件的fd（fd：file descriptor）。

kill进程是通过截断proc文件系统中的文件可以强制要求系统回收分配给正在使用的的文件。

这是一项高级技术，仅到管理员确定不会对运行中的进程造成影响时使用。应用程序对这种方

式支持的并不好，当一个正在使用的文件被截断可能会引发不可预知的问题

 

例如，根据之前lsof的输出：

1.$ file /proc/25575/fd/33

2./proc/25575/fd/33: broken symbolic link to `/oradata/DATAPRE/UNDOTBS009.dbf (deleted)'

3.$ echo > /proc/25575/fd/33

 

所以我还是采用停应用来解决

restart oracle数据库，发现/home/oracle/admin/dbticb/bdump/alert_dbticb.log对应的空间被释放

在查看磁盘空间的使用情况，发现空间已经回收了

 

[root@ticketb ~]# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda1 981M 203M 729M 22% /

none 16G 0 16G 0% /dev/shm

/dev/sda9 2.9G 37M 2.7G 2% /tmp

/dev/sda7 4.9G 1.9G 2.7G 42% /usr

/dev/sda8 2.9G 145M 2.6G 6% /var

/dev/mapper/vghome-lvhome

20G 2.6G 16G 15% /home

/dev/mapper/vgoradata-lvoradata

144G 48G 90G 35% /u01/oradata

/dev/mapper/vgbackup-lvbackup

193G 7.8G 175G 5% /u01/backup