Linux中删除文件，磁盘空间未释放问题追踪

在客户使用我们产品后，发现一个问题：在删除了文件后，磁盘空间却没有释放。是有进程在打开这个文件，还是其他情况？我们一起来看看一下两个场景

一. 场景一：进程打开此文件

当一个文件正在被一个进程使用时，用户删除此文件，文件只会从目录结构中删除，但并没有从磁盘删除。当使用这个文件的进程结束后，文件才会真正的从磁盘删除，释放占有的空间。

我们发现剩余磁盘空间比较少时，回去删除一些大的临时文件或者log文件，如果删除之后会发现磁盘空间并未减少，那么可以通过“lsof”命令去查看正在使用该文件的进程，然后再重启该进程或者服务。

【例子】

现在发现磁盘空间的占用了99%，剩余空间只剩下522M。

+++++++++++++++++++++++++++++++++++++++

SUSE11X64-001:/test # df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda2 29G 27G 522M 99% /

devtmpfs 972M 116K 972M 1% /dev

tmpfs 972M 0 972M 0% /dev/shm

+++++++++++++++++++++++++++++++++++++++

找到一个文件"vmcore"占用了接近900M空间，但这个文件不需要再使用了，于是采用“rm”命令删除此文件，可是删除后，发现磁盘空间并没有真正的减少。

SUSE11X64-001:/test # rm vmcore

SUSE11X64-001:/test # df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda2 29G 27G 522M 99% /

devtmpfs 972M 116K 972M 1% /dev

tmpfs 972M 0 972M 0% /dev/shm

//10.204.16.2/home/splx/iceking 6.3T 1.6T 4.7T 25% /mnt/iceking

也就是说很有可能有其他进程正在使用这个文件，使用“lsof”命令去查看正在使用该文件的进程。

+++++++++++++++++++++++++++++++++++++++

SUSE11X64-001:/test # lsof | grep vmcore

a.out 2610 root 3r REG 8,2 941331144 1643779 /test/vmcore (deleted)

+++++++++++++++++++++++++++++++++++++++

进程号为2610(进程名为"a.out")的进程，正在使用vmcore文件，也可以看到其后有“deleted”：其表示正在使用的文件被删除，但并没有真正从磁盘上移除。

现在我们删除这个进程，并查看磁盘空间此时占用率降低为95%，剩余空间增加到1.4G。

+++++++++++++++++++++++++++++++++++++++

SUSE11X64-001:/test # df -h

Filesystem Size Used Avail Use% Mounted on

/dev/sda2 29G 26G 1.4G 95% /

devtmpfs 972M 116K 972M 1% /dev

tmpfs 972M 0 972M 0% /dev/shm

+++++++++++++++++++++++++++++++++++++++

二. 场景二：内核模块Bug

在文件系统处理文件需要的信息都存放在索引节点(inode)中，如果在删除文件的时候索引节点的引用计数不为0（表示文件正在被使用），则不会在磁盘中真正的删除文件，从而保证正在使用此文件的进程能够正常的处理文件。

首先我们一起来看一下内核中关于文件系统的一些关键数据结构的关联，当一个进程打开一个文件后，便会在内核中创建一个file对象，这个对象主要描述了进程如何与文件进行交互。file对象中将指向一个dentry结构（目录项），目录项中描述了目录项名称，父目录项信息，子目录项信息等。而dentry中的d_inode所指向的inode节点中则包含了实际的文件存储在磁盘上的信息。

当多个进程打开同一个文件时，内核中变会创建相应的file对象，但是他们都公用同一个dentry，只不过每一次打开文件dentry的引用计数d_count加1。并且对于打开的同一个文件而言，inode也是唯一的，inode的引用计数i_count一般为文件硬链接的数目。看过一些中文博客，说“同一个文件，每打开一次，则inode中引用计数i_count则加1”，这种说法通过我的验证结果是错误的。实验结果是：对于同一个文件，每打开一次，则inode中的引用计数不变，但相应的dentry引用计数加1.

这次客户在删除文件后，磁盘空间没有释放，通过"lsof"命令也没有找到正在占用此文件的进程。于是再次怀疑这是由于产品的内核模块早成的。后经分析得到：在上一篇博文《Linux Kernel模块内存泄露查找 (2)》中解释过由于在产品内核模块中，对dentry引用，并使用完之后并没有对其引用计数减1，从而造成内存泄露。在这种情况下，dentry不会被释放，则inode也就一直被引用着，从而也导致了即使删除文件，也不会从磁盘删除。

而且针对以上的问题和分析，如果不能及时给客户修这个问题，那也只能让其重新启动OS，空闲的磁盘空间才会释放出来。