Interviewer: will RM delete the file space and release it?

Posted on

Interviewer: will RM delete the file space and release it?

From: programming pearls

In Linux, did you ever think that if you used RM to delete a file, the space occupied would be released? Things may not always be what you want.

Generates a random content file of a 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’ve chosen one of the result displays here (you can choose any mount directory), and I’m ready 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, and then look at the boot:

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

Here you don’t have to worry about how much more, you just need to pay attention to the increase of files under / boot.

Test procedure:

int main(void)
{    FILE *fp = NULL;   
fp = fopen("/boot/test.txt", "rw+");   
if(NULL == fp)    
perror("open file failed");   
return -1;   
//do nothing       sleep(1);   
return 0;

As for the program itself, there is no real thing to do, that is, to open a file and keep looping. Compile and run:

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

Open another window and delete test.txt :

$ rm /boot/test.txt

Take a look at the boot space

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

Eh? How the size of the space has not changed at all!! Did you delete it by using RM?

Let’s stop the openFile program and have a look:

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

Dear, the space is released immediately, that is, our files are deleted as expected.

When can a file be deleted?

In fact, only when the reference count of a file is 0 (including the number of hard links), unlink deletion can be called. As long as it is not 0, it will not be deleted. The so-called deletion is just the deletion of the link between the file name and the inode. As long as the new data is not rewritten, the block data block on the disk will not be deleted. Therefore, you will see that even if the deletion library runs out of the way, some data can still be recovered. In other words, when a program opens a file (gets the file descriptor), its reference count will be + 1. Although RM seems to have deleted the file, in fact, it will only reduce the reference count by 1, but because the reference count is not 0, the file will not be deleted.

struct inode {
struct hlist_ node   i_ Hash; / * pointer to hash linked list*/
struct list_head    i_list; /* backing dev IO list */
struct list_ head    i_ Sb_ List; / * inode linked list of superblocks*/
struct list_ head    i_ Dentry; / * refers to the directory entry object linked list header of inode*/
unsigned long    i_ Ino; / * index node number*/
atomic_ t         i_ Count; / * reference count*/
unsigned int     i_ Nlink; / * number of hard links*/

As for the details, there are many contents (for example, the number of hard links will also affect whether the files are deleted). Here we will not expand them one by one.

How to free the space occupied by deleted files?

As mentioned above, restart the process of opening the file. But is there any way to find out which files have been deleted but opened by some processes?

Nature has a way:

$ lsof |grep deleted

The files marked as deleted are such files.

In fact, in the previous example, we can easily observe that the openFile program runs, test.txt File deleted:

$ ls -al /proc/`pidof openFile`/fdtotal 0
Lrwx ------ 1 root root root 64 May 4 09:27 0 - > / dev / PTS / 25
Lrwx ------ 1 root root root 64 May 4 09:27 1 - > / dev / PTS / 25
Lrwx ------ 1 root root root 64 May 4 09:27 2 - > / dev / PTS / 25
Lrwx ------ 1 root root root 64 May 4 09:27 3 - > / boot/ test.txt  (deleted)

See, test.txt And then there’s the word deleted.

Since we have said that the file has not been deleted in this case, can it be recovered? It’s actually readable.


In fact, when such files are deleted, they often appear in the log files of the program. Maybe you have a regular task to clean up the log files generated by the program. However, if the program forgets to close the handle, the disk space will not be released. Finally, you think that the files have been deleted, but the disk is still occupied. Therefore, form a good habit, open the file, when not in use, remember to close the file descriptor.

If you find that a large number of files have been deleted, but the space has not returned to normal, you may as well see if there are programs to open these files.

Interviewer: will RM delete the file space and release it?

Leave a Reply

Your email address will not be published.