rm删除文件空间并释放？多么天真！在linux中删除文件，你有没有天真地以为用rm删除一个文件，占用的空间就被释放了？事情可能并不总是如愿。不相信吗？查看下面的示例。生成指定大小的随机内容文件。我们先看看当前每个挂载目录的空间大小：$df-h/dev/sda11454M280M147M66%/boot我选择了其中一个结果显示在这里（可以选择任意挂载目录），然后准备生成文件在/boot下。首先我们生成一个50M的文件：$ddif=/dev/urandomof=/boot/test.txtbs=50Mcount=1其中dd命令可以参考《dd命令实用详解》，关于/dev/urandom，在中已经有了介绍。至此，我们生成了一个大小为50M的文件，然后在boot下查看：$df-h/dev/sda11454M312M115M74%/boot这里多多少不用关心，只需要注意,/boot下的文件数量增加了。测试程序#include#includeintmain(void){FILE*fp=NULL;fp=fopen("/boot/test.txt","rw+");if(NULL==fp){perror("openfilefailed");return-1;}while(1){//donothingsleep(1);}fclose(fp);return0;}至于程序本身，并没有做任何实际的事情，直接打开A文件，然后一直循环。编译运行：$gcc-oopenFileopenFile.c$./openFile另开一个窗口，删除test.txt：$rm/boot/test.txt再看看引导空间：$df-hdev/sda11454M312M115M74%/boot咦？空间的大小怎么一点都没变！！明明是用rm删除的？我们先停止openFile程序，再看：$$df-h/dev/sda11454M280M147M66%/boot好了，空间马上就释放了，也就是果不其然，我们的文件被删除了。什么情况下文件会被删除？实际上，只有当一个文件的引用计数为0（包括硬链接数）时，才有可能调用unlink删除。只要不为0，就不会被删除。所谓删除无非就是删除文件名到inode的链接。只要不改写新数据，磁盘上的块数据块就不会被删除。因此，你会看到即使库被删除跑掉了，一些数据还是可以恢复的。也就是说，当一个程序打开一个文件（获取文件描述符）时，它的引用计数会+1。rm虽然看起来是删除文件，但实际上只是将引用计数减1，但是因为引用计数不为0，所以文件不会被删除。structnode{structhlist_nodei_hash;/*hash链表指针*/structlist_headi_list;/*backingdevIOlist*/structlist_headi_sb_list;/*超级块的inode链表*/structlist_headi_dentry;/*指向inode的目录项对象链表头*/unsignedlongi_ino;/*indexnodeNo.*/atomic_ti_count;/*Referencecount*/unsignedinti_nlink;/*hardlinks数量*/...里面有很多细节（比如hardlinks的数量也会影响文件是否是删），这里就不一一展开了。如何释放被删除文件占用的空间？关于release，上面说了，重启打开文件的进程即可。但是有没有办法找出哪些文件已被删除，但仍被某些进程打开？自然有一个方法：$lsof|grepdeleted标记为已删除的文件就是这样的文件。其实在前面的例子中，我们也可以很容易的观察到（运行openFile程序，删除test.txt文件）：$ls-al/proc/`pidofopenFile`/fdtotal0lrwx-----1rootroot645月409:270->/dev/pts/25lrwx-----1rootroot645month409:271->/dev/pts/25lrwx-----1rootroot645month409:272->/dev/pts/25lrwx------1rootroot64May409:273->/boot/test.txt(deleted)看到没有，test.txt后面也有deleted这个词。既然我们说了这种情况下文件没有被删除，那么是否可以恢复呢？其实还是可以读的。总结其实这种文件被删除了，它经常出现在程序的日志文件中。也许你有一个计划任务要清理程序产生的日志文件，但如果程序本身忘记关闭句柄，就会导致磁盘空间不足。释放，最后，你以为文件已经删除了，但是磁盘还是被占用了。因此，养成一个好习惯。打开文件后，记得在不使用时关闭文件描述符。如果你发现大量的文件被删除了，但是空间并没有恢复正常，那么你不妨检查一下是否有打开这些文件的程序。
