From: programming Pearl
In Linux, have you ever naively thought that when you delete a file with rm, the occupied space will be released? Things may not always go as expected.
Generate a random content file of specified size
Let's take a look at the current space size of each mounted Directory:
$ df -h /dev/sda11 454M 280M 147M 66% /boot
I have selected one of the result displays here (you can select any mounting directory), and then prepare to generate a file under /boot.
First, we generate a file of 50M size:
$ dd if=/dev/urandom of=/boot/test.txt bs=50M count=1
So far, we have generated a file with a size of 50M. Let's look at the boot:
$ df -h /dev/sda11 454M 312M 115M 74% /boot
Here, you don't need to worry about how much more there are. You just need to pay attention to the increase in the number of files under /boot.
Test procedure:
#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; }
As for the program itself, it doesn't really do anything. It just opens a file and keeps cycling. Compile and run:
$ gcc -o openFile openFile.c $ ./openFile
Open another window and delete test Txt:
$ rm /boot/test.txt
Take another look at the boot space:
$ df -h dev/sda11 454M 312M 115M 74% /boot
Eh? How come the space size hasn't changed at all!! Did Mingming delete it with rm?
Let's stop the openFile program and see:
$$ df -h /dev/sda11 454M 280M 147M 66% /boot
Darling, the space will be released immediately, that is, our files will be deleted as expected.
When will a file be deleted?
In fact, unlink deletion can be called only when the reference count of a file is 0 (including the number of hard links). As long as it is not 0, it will not be deleted. The so-called deletion is just the deletion of the link from the file name to the inode. As long as the new data is not rewritten, the block data blocks on the disk will not be deleted. Therefore, you will see that even if the deleted database runs away, some data can be recovered. In other words, when a program opens a file (obtains the file descriptor), its reference count will be +1. Although rm seems to delete the file, it will actually reduce the reference count by 1. However, since the reference count is not 0, the file will not be deleted.
struct inode { struct hlist_node i_hash; /* hash Pointer to linked list*/ struct list_head i_list; /* backing dev IO list */ struct list_head i_sb_list; /* inode linked list of super block*/ struct list_head i_dentry; /* Directory item object linked header referencing inode*/ unsigned long i_ino; /* Inode number*/ atomic_t i_count; /* Reference count*/ unsigned int i_nlink; /* Number of hard links*/
There are many details about it (for example, the number of hard links will also affect whether the file is deleted), which will not be expanded here.
How to free the space occupied by deleted files?
As for release, you can restart the process of opening the file. But is there any way to find out which files were deleted, but still opened by some process?
Nature has its way:
$ lsof |grep deleted
The files marked as deleted are such files.
In fact, in the previous example, we can also easily observe (the openFile program runs, and the test.txt file is deleted):
$ ls -al /proc/`pidof openFile`/fdtotal 0 lrwx------ 1 root root 64 5 month 4 09:27 0 -> /dev/pts/25 lrwx------ 1 root root 64 5 month 4 09:27 1 -> /dev/pts/25 lrwx------ 1 root root 64 5 month 4 09:27 2 -> /dev/pts/25 lrwx------ 1 root root 64 5 month 4 09:27 3 -> /boot/test.txt (deleted)
See, test Txt followed by the word deleted.
Since we have said that the file has not been deleted in this case, can it be restored? It can actually be read.
summary
In fact, when such files are deleted, they often appear in the program's log files. Maybe you have a scheduled task to clean up the log files generated by the program. However, if the program itself forgets to close the handle, the disk space will not be released. In the end, you think that all the files have been deleted, but the disk is still occupied. Therefore, make it a good habit to close the file descriptor after opening the file and when not in use.
If you find that Mingming has deleted a large number of files, but the space has not returned to normal, you might as well see if there are programs to open these files.