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

http://blog.csdn.net/cjf_iceking/article/details/37593963

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

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

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

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

    【例子】

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

[plain]  view plain  copy

1. SUSE11X64-001:/test # df -h  
2. Filesystem                       Size  Used Avail Use% Mounted on  
3. /dev/sda2                         29G   27G  522M  99% /  
4. devtmpfs                         972M  116K  972M   1% /dev  
5. tmpfs                            972M     0  972M   0% /dev/shm  

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

[plain]  view plain  copy

1. SUSE11X64-001:/test # rm vmcore   
2. SUSE11X64-001:/test # df -h  
3. Filesystem                       Size  Used Avail Use% Mounted on  
4. /dev/sda2                         29G   27G  522M  99% /  
5. devtmpfs                         972M  116K  972M   1% /dev  
6. tmpfs                            972M     0  972M   0% /dev/shm  
7. //10.204.16.2/home/splx/iceking  6.3T  1.6T  4.7T  25% /mnt/iceking  

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

[plain]  view plain  copy

1. SUSE11X64-001:/test # lsof | grep vmcore  
2. a.out      2610       root    3r      REG                8,2 941331144    1643779 /test/vmcore (deleted)  

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

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

[plain]  view plain  copy

1. SUSE11X64-001:/test # df -h  
2. Filesystem                       Size  Used Avail Use% Mounted on  
3. /dev/sda2                         29G   26G  1.4G  95% /  
4. devtmpfs                         972M  116K  972M   1% /dev  
5. tmpfs                            972M     0  972M   0% /dev/shm  

二. 场景二：文件有硬链接

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

三. 场景三：内核模块Bug

    我们一起来看一下内核中关于文件系统的一些关键数据结构的关联，当一个进程打开一个文件后，便会在内核中创建一个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，空闲的磁盘空间才会释放出来。