Find and remove large files that are open but have been deleted
When a process opens a file and then unlinks it, the file’s resources remain in use by the process, but the file’s directory entries are removed. Hence, even when you know the directory where the file once resided, you can’t detect it with ls.
This can be an administrative problem when the unlinked file is large, and the process that holds it open continues to write to it. Only when the process closes the file will its resources, particularly disk space, be released.
Lsof can help you find unlinked files on local disks. It has an option, +L, that will list the link counts of open files. That helps because an unlinked file on a local disk has a zero link count. Note: this is NOT true for NFS files, accessed from a remote server.
- Use the option to list all files and look for a zero link count in the NLINK column
|
1 |
<strong>$lsof +L</strong> |
|
1 2 3 4 5 |
<strong>COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME </strong> networkse 826 atyagi txt REG 1,4 32768 0 11651355 /private/var/db/mds/messages/1448332820/se_SecurityMessages networkse 826 atyagi txt REG 1,4 25923264 1 1557070 /usr/share/icu/icudt57l.dat networkse 826 atyagi txt REG 1,4 698896 1 6111216 /usr/lib/dyld |
You can also select upper bound for Nlink with +L<upper bound value>
|
1 2 3 4 |
<strong>$lsof +L </strong><strong>COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME </strong> Google 93071 atyagi976 txt REG 1,4 131072 0 11925760 /private/var/folders/_s/9ww5612s7nq3vyp8qx3mh4dsb57lhm/T/.com.google.Chrome.bg7wQk Google 93071 atyagi976 6r REG 1,4 131072 0 11925760 /private/var/folders/_s/9ww5612s7nq3vyp8qx3mh4dsb57lhm/T/.com.google.Chrome.bg7wQk |
You can also give the mount path using
|
1 |
$ lsof -a +L1 /home |
more options here: https://www.akadia.com/services/lsof_quickstart.txt
https://unix.stackexchange.com/questions/68523/find-and-remove-large-files-that-are-open-but-have-been-deleted
