On Linux, have you ever thought that using RM to delete a file would free up space? Things may not always go your way.

Generates a random content file of the specified size

Let’s take a look at the current size of each mount directory:

$ df -h
/dev/sda11      454M  280M  147M  66% /bootCopy the code

I’ve picked one of the results to show here (you can choose any mount directory), and I’m ready to generate a file under /boot.

First we generate a 50M file:

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

At this point, we have created a 50M file, and look at boot:

$ df -h
/dev/sda11      454M  312M  115M  74% /bootCopy the code

You don’t have to worry about how much more, you just have to worry about more 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;
}Copy the code

As for the program itself, it doesn’t actually do anything, except open a file and loop through it. Compile and run:

$ gcc -o openFile openFile.c
$ ./openFileCopy the code

Open another window and delete test.txt:

$ rm /boot/test.txtCopy the code

Let’s look at the boot space:

$ df -h
dev/sda11      454M  312M  115M  74% /bootCopy the code

Yi? The size of the space has not changed at all!! Delete it using rm.

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

? df -h
/dev/sda11      454M  280M  147M  66% /bootCopy the code

Boy, space will be free soon, which means our files will be deleted as expected.

When can a file be deleted?

In fact, unlink deletion is only possible if a file’s reference count is zero (including the number of hard links), and as long as it is not zero, it will not be deleted. A delete is simply a deletion of the link between the file name and the inode. As long as new data is not written to the disk, the block is not deleted. Therefore, you can see that some data can be recovered even if the deletor runs out. In other words, when a program opens a file (and gets the file descriptor), its reference count is increased by 1. Rm appears to delete the file but actually just decreases the reference count by 1, but the file is not deleted because the reference count is not zero.

struct inode { struct hlist_node i_hash; */ struct list_head i_list; /* backing dev IO list */ struct list_head i_sb_list; */ struct list_head i_dentry; /* unsigned long i_ino; /* index node number */ atomic_t i_count; /* Reference count */ unsigned int i_nlink; /* Number of hard links */Copy the code

There are a lot of details (such as the number of hard links can also affect whether a file is deleted), but I won’t go into all of them here.

How do I release space occupied by deleted files?

As mentioned earlier, just restart the process that opened the file. But is there a way to find out which files were deleted but still opened by some process?

Nature has a method:

$lsof | grep does which is marked as does file, this is some of the files.

The openFile program is running, and the test.txt file is deleted:

$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)Copy the code

See, test. TXT has the word deleted in it.

Since we have said that the file was not deleted in this case, can it be restored? You can actually read it.

Did the interviewer tell me that after RM deleted the file, the space was released? What should I say

conclusion

Actually for this file is deleted, often appeared in the process of the log file, may you have a task to clean up the program generated log files regularly, but forget to close the handle, if the program itself will result in disk space is not released, would eventually you think files have been deleted, but the disk is still occupied. So make it a good habit to close the file descriptor when you’re not using it.

If you find that you have deleted a large number of files, but the space is not restored, you might want to see if there are programs that open those files.

Author: Programming abecas