proc/21200/fd/3: symbolic link to `/home/ user/realfile' <= openfile realfile & # open the file for append access, then sleep We can easily reproduce the above as shown below: dd if=/dev/zero of=realfile bs=1M count=10 If you accumulating a large number of deleted file instances that are open by processes, typically this points to a poorly written program that "forgets" to close open files once they are done with them or application architectural issues such that multiple deleted instances of one or more files accumulate within the filesystem. Since the copy of that file was open at the time it was deleted from the filesystem directory hierarchy, the symbolic link is broken (doesn't point to a visible file within the filesystem) - but it also means the space that that file is occupying on disk cannot be recovered/reclaimed aka the on-disk file is essentially in a 'busy' state and cannot be actually removed from the filesystem/disk until all processes that currently have it open, close their access to that instance of the file. It simply means the copy of /oradata/DATAPRE/file.dbf that process 25575 has open on file descriptor 33 was deleted while this process was running. Log Reaper will allow you to visualize and quickly narrow down the lsof data to exactly the subset you want to see Therefore such processes may need to be restarted before that file's space will be cleared up on the filesystem. On Linux or Unix systems, deleting a file via rm or through a file manager application will unlink the file from the file system's directory structure however, if the file is still open (in use by a running process) it will still be accessible to this process and will continue to occupy space on disk. To identify the used file size (in blocks), use the command below: # lsof -Fn -Fs |grep -B1 -i deleted | grep ^s | cut -c 2- | awk '' The same reason will cause different disk usage from du command and df command, please refer to Why does df show bigger disk usage than du? proc/25575/fd/33: broken symbolic link to `/oradata/DATAPRE/file.dbf (deleted)' $ echo > /proc/pid/fd/fd_numberįor example, from the lsof output above: $ file /proc/25575/fd/33 Applications may not be designed to deal elegantly with this situation and may produce inconsistent or undefined behavior when files that are in use are abruptly truncated in this manner. This is an advanced technique and should only be carried out when the administrator is certain that this will cause no adverse effects to running processes. If a graceful shutdown does not work, then issue the kill command to forcefully stop it by referencing the PID.Īlternatively, it is possible to force the system to de-allocate the space consumed by an in-use file by forcing the system to truncate the file via the proc file system.
#Linux clean disk space free
The lsof output shows the process with pid 25575 has kept file /oradata/DATAPRE/file.dbf open with file descriptor (fd) number 33.Īfter a file has been identified, free the file used space by shutting down the affected process. Note: check either the filesystem path within NAME field or the device number under DEVICE to match the filesystem of interest.
When you perform a df, the storage shows 90+% utilized, however, there is not really that much written to that space.įirst, obtain a list of deleted files which are still held open by applications: $ lsof | egrep "deleted|COMMAND"ĬOMMAND PID TID TASKCMD USER FD TYPE DEVICE SIZE/OFF NODE NAME The lsof command shows the following output before restarting the java process COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME The file was previously deleted, but only stopping and restarting the jvm/java process released the disk space. The OS was holding several very large log files open with some as large as ~30G.
0 kommentar(er)
