Article Directory
For the full Linux disk problem,
we usually deal with the idea is to dulook for clean up of large files,
and then delete the temporary use of the disk to take the lead down to ensure the disk can continue to be written as soon as possible.
However, in some cases, the processing effect is different, and
du/dfthe results presented may be confusing.
Below, I will share the bizarre disk full problem encountered in the next few jobs.
1. Hidden files that are ignored
1. Know swapfile
Linux swap file swapfile generation scenarios are more common, and it also exists in the form of hidden files,
so here we mainly talk about hidden files such as swapfile.
When you open a file with vim, it will have a .swptemporary swap file to hide, to back up the contents of the buffer.
When the file is closed abnormally (such as closing the terminal directly or the computer is powered off, etc.), the .swpfile will not be deleted, so you can use this file to restore the file. (Note that when a normal shutdown, the file will be deleted; and if only to read the file, no .swpfile)
Also, if vim quit unexpectedly reopened the secondary file editing,
then the old .swpfile will remain, and a new .swotemporary hidden files.
If vim exits abnormally during the second editing,
new temporary hidden files will continue to be generated .swn、.swm、 .swl...
2. Treatment suggestions
The disk usage of some hidden files is also quite large:
:/tmp # ll -rth | grep G
total 17.7G
-rw------- 1 xxxx users 17.6G 2020-02-12 18:27 .sqlkfJTFl.swp
Therefore, sometimes when the disk is full due to large hidden files, if you fail to find these hidden files, you will feel bizarre and confused.
Therefore, the investigation disk full problem,
can perform vim -rto view and size of all temporary swap files under examination;
or by ls -lhaa look at the size of all the hidden files are listed.
More rudely,
if you don't want to keep the swapfile feature, you can consider turning off swapfile:
vim /etc/vimrc
# 添加如下配置
set noswapfile # 禁止在编辑时候产生此文件；
But note that this is only in the case where the file loss can be tolerated ;
if the file loss cannot be tolerated, it is still recommended to open the swapfile :
vim /etc/vimrc
# 添加如下配置
set swapfile # 则是在编辑时候产生此文件；
2. Unreleased deleted files
1. Du and df are inconsistent
If the hidden file excluded factors,
or find duout the size of the strange,
such as the dudiscovery did not use full disk, but dfto see the disk usage is 100 percent.
What could be the reason for this?
At this time, usually you have to suspect that there are some deleted files, also did not handle some of the processes hold live release,
resulting in files Although these have been removed, and indeed can not see, but still occupied disk space;
resulting in duand dfout Inconsistent disk usage results.
2. Treatment suggestions
By executing lsof | grep deletedyou can not find those files and processes to free up disk space,
and then by restarting the corresponding process, we can achieve the purpose of the release of the deleted files take up space.
This post "Common Mistakes in Clearing Hot Files" explains the scenarios and processing methods of "deleted files still occupy disk".
In addition, in this case, there is a wrong approach, here to remind the next:
some students after finding unreleased deleted files pid,
might directly through kill pidto achieve the purpose of the release of deleted files.
This approach can indeed release deleted files, thereby freeing up disk space,
but this approach has side effects, and the harm can be large or small.
If you operate this way in an offline environment, the impact is generally small;
but if you operate it like this in a production environment, it may cause a malfunction.
We assume such a scenario:
a program in the production environment has not released log files due to a certain bug,
and the log files written in time-sharing have an expired deletion mechanism. If
this continues,
it will be found on the server. There are a large number of expired deleted log files that still occupy disk space until the risk of disk fullness occurs.
So this time if directly kill pidhandled, then it directly to the production environment of online programs to directly kill;
the consequences can be imagined: Before this program is the daemon pull up, this service is not available.
Third, the unsettled case caused by mounting
1. The disappearing space
If you do ls -lhanot find large hidden files,
execute lsof | grep deletedalso found no unreleased deleted files;
But dfsee the root directory does reach 100%, and
while duout of the root of the actual use of space but did not use full.
What could be the reason for this?
When this happens,
please recall the recent machine with abnormal disk. Has the disk been overhauled or replaced?
The root of the emergence of this strange phenomenon,
usually the time in maintenance / replacement disk (here assumed to be the replacement /data1),
the new disk will not mount began to /data1write the data, and
this time not due to mount the new disk, so write The data occupies the space of the root directory .
Then for good /data1after the disk and remount up,
originally placed in /data1the data, it will not appear on the mount plate, or continue to occupy the space of the root directory.
So at this time there will be such a phenomenon:
after mounting, it du /data1 is not big,
but the data written in the directory before mounting /data1 actually occupies the root directory space;
and this data is invisible after mounting, so it is difficult Find.
Then you will find that some space in the root directory seems to have disappeared out of thin air, which is quite strange.
2. Treatment suggestions
2.1 Solution
How can I confirm that the new mount disk concealed some data?
umountDrop the new mount disk /data1 , and then look at the space occupied by /data1.
If umountTip busy:
by performing
fuser -kmvi /data1 && umount /data1
solve.
After uninstalling, you will find the up / down data1 directory does have a large number of files
after deletion, then mount -aremount,
then the root of the disappearance of disk space, the general will be able to get it back.
2.2 Test verification
If you are not at ease, after cleaning up the data and mounting it again, you can simply test it:
Pass
dd if=/dev/zero of=/data1 bs=1M count=20000
To /data1probably write a 20G data,
and then observe the space under the root directory is affected,
If it is not affected, the problem is solved!
2.3 Give a suggestion
For bizarre problems such as the root directory: It is
recommended to check the space usage of the root directory every time before replacing the disk and remounting;
if there is an error in writing data, it needs to be cleaned up in time , and then the new disk is mounted. , Remember.