rm刪除文件空間就釋放了嗎?太天真了!

[[325464]]

刪除一個文件

在Linux，你是不是曾經(jīng)天真的以為，使用rm刪除一個文件，占用的空間就釋放了?事情可能不是常常如人意。

不信嗎?來看下面的例子。

產(chǎn)生一個指定大小的隨機內(nèi)容文件

我們先看一下當(dāng)前各個掛載目錄的空間大小：

$ df -h 
/dev/sda11      454M  280M  147M  66% /boot 

我這里挑選了其中一個結(jié)果展示(你可以選擇任一掛載目錄)，接下來準備在/boot下生成一個文件。

首先我們產(chǎn)生一個50M大小的文件：

$ dd if=/dev/urandom of=/boot/test.txt bs=50M count=1 

其中dd命令可以參考《dd命令實用詳解》，而關(guān)于/dev/urandom，在《Linux特殊設(shè)備文件你知道嗎》中已經(jīng)有介紹。

至此，我們產(chǎn)生了一個50M大小的文件，再看boot下：

$ df -h 
/dev/sda11      454M  312M  115M  74% /boot 

這里你不用關(guān)心到底多了多少，你只需要關(guān)注，/boot下的文件增多了。

測試程序

#include<stdio.h> 
#include<unistd.h> 
int main(void) 
{ 
    FILE *fp = NULL; 
    fp = fopen("/boot/test.txt", "rw+"); 
    if(NULL == fp) 
    { 
       perror("open file failed"); 
       return -1; 
    } 
    while(1) 
    { 
       //do nothing 
       sleep(1); 
    } 
    fclose(fp); 
    return 0; 
} 

至于程序本身，也沒干啥實際的事情，就是打開一個文件，然后一直循環(huán)。

編譯并運行：

$ gcc -o openFile openFile.c 
$ ./openFile 

打開另外一個窗口，刪掉test.txt：

$ rm /boot/test.txt 

再看一下boot空間：

$ df -h 
dev/sda11      454M  312M  115M  74% /boot 

咦?空間大小怎么一點都沒變!!明明使用rm把它刪除了啊?

我們把openFile程序停掉，再看看：

$$ df -h 
/dev/sda11      454M  280M  147M  66% /boot 

乖乖，空間馬上就釋放掉了，也就是按照預(yù)期，我們的文件被刪除了。

一個文件什么情況下才會被刪除?

實際上，只有當(dāng)一個文件的引用計數(shù)為0(包括硬鏈接數(shù))的時候，才可能調(diào)用unlink刪除，只要它不是0，那么就不會被刪除。所謂的刪除，也不過是文件名到 inode 的鏈接刪除，只要不被重新寫入新的數(shù)據(jù)，磁盤上的block數(shù)據(jù)塊不會被刪除，因此，你會看到，即便刪庫跑路了，某些數(shù)據(jù)還是可以恢復(fù)的。

換句話說，當(dāng)一個程序打開一個文件的時候(獲取到文件描述符)，它的引用計數(shù)會被+1，rm雖然看似刪除了文件，實際上只是會將引用計數(shù)減1，但由于引用計數(shù)不為0，因此文件不會被刪除。

struct inode { 
struct hlist_node   i_hash; /* hash鏈表的指針 */ 
struct list_head    i_list; /* backing dev IO list */ 
struct list_head    i_sb_list; /* 超級塊的inode鏈表 */ 
struct list_head    i_dentry; /* 引用inode的目錄項對象鏈表頭 */ 
unsigned long    i_ino; /* 索引節(jié)點號 */ 
atomic_t         i_count; /* 引用計數(shù) */ 
unsigned int     i_nlink; /* 硬鏈接數(shù)目 */ 
...... 

關(guān)于里面的細節(jié)，還有很多內(nèi)容(如硬鏈接數(shù)量也會影響文件是否被刪除)，這里不一一展開。

如何釋放已經(jīng)被刪除文件占用的空間?

關(guān)于釋放，前面已經(jīng)說了，重啟打開該文件的進程即可。但是有沒有方法找到哪些文件被刪除了，但還是被某些進程打開了呢?

自然是有方法的：

$ lsof |grep deleted 

其中被標記為deleted的文件，就是這樣的一些文件。

其實在前面的例子中，我們也可以很容易觀察到(openFile程序運行，test.txt文件被刪除)：

$ ls -al /proc/`pidof openFile`/fd 
total 0 
lrwx------ 1 root root 64 5月   4 09:27 0 -> /dev/pts/25 
lrwx------ 1 root root 64 5月   4 09:27 1 -> /dev/pts/25 
lrwx------ 1 root root 64 5月   4 09:27 2 -> /dev/pts/25 
lrwx------ 1 root root 64 5月   4 09:27 3 -> /boot/test.txt (deleted) 

看見沒有，test.txt后面還有deleted字樣。

既然我們都說了，這樣的情況下文件是沒有被刪除的，那么還能不能恢復(fù)呢?實際上還是可以讀取的。

總結(jié)

實際上對于這種文件被刪除了，常常出現(xiàn)于程序的日志文件中，可能你有一個定時任務(wù)去清理程序產(chǎn)生的日志文件，但是如果程序本身忘記關(guān)閉句柄，就會導(dǎo)致磁盤空間得不到釋放，最終就是你認為文件都被刪除了，但是磁盤卻依然被占著。所以，養(yǎng)成好習(xí)慣，打開文件后，不用時，記得關(guān)閉文件描述符。

如果發(fā)現(xiàn)明明已經(jīng)刪除了大量文件，但是空間卻并沒有恢復(fù)正常，那么不妨看看是不是還有程序打開了這些文件。