在客戶使用我們產品後，發現一個問題：在刪除了檔案後，磁碟空間卻沒有釋放。是有程序在開啟這個檔案，還是其他情況？我們一起來看看一下兩個場景

一. 場景一：程序開啟此檔案

    當一個檔案正在被一個程序使用時，使用者刪除此檔案，檔案只會從目錄結構中刪除，但並沒有從磁碟刪除。當使用這個檔案的程序結束後，檔案才會真正的從磁碟刪除，釋放佔有的空間。

    我們發現剩餘磁碟空間比較少時，回去刪除一些大的臨時檔案或者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
 

SUSE11X64-001:/test # lsof | grep vmcore
a.out      2610       root    3r      REG                8,2 941331144    1643779 /test/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，空閒的磁碟空間才會釋放出來。