Add support for detecting files with a 0 link count

[atc0005]

Overview

From lsof-org/lsof#65 (comment):

a. Finding an Unlinked Open File

A pesky variant of a file that is filling a file system is an
unlinked file to which some process is still writing. 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.

You could use the option to list all files and look for a zero
link count in the NLINK column -- e.g.,

$lsof +L
COMMAND   PID USER   FD  TYPE DEVICE SIZE/OFF NLINK  NODE NAME
...
less    25366  abe  txt  VREG    6,0    40960     1 76319 /usr/...
...
less 25366 abe 3r VREG 6,0 17360 0 98768 / (/dev/sd0a)

Better yet, you can specify an upper bound to the +L option, and
lsof will select only files that have a link count less than the
upper bound. For example:

$ lsof +L1
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NLINK  NODE NAME
less    25366  abe    3r  VREG    6,0    17360     0 98768 / (/dev/sd0a)

You can use lsof's -a (AND) option to narrow the link count search
to a particular file system. For example, to look for zero link
counts on the /home file system, use:

$ lsof -a +L1 /home

But I don't understood why I'm getting so big difference between lsof's output(for eg. lsof -a +L1) and output of my script which parse every PID stored in procfs. I mean the difference in count of unlinked files.

and the reply at lsof-org/lsof#65 (comment):

How about lsof -K -a +L1 ?

References

• Show deleted files lsof-org/lsof#65
• https://lsof.readthedocs.io/en/latest/tutorial/#finding-an-unlinked-open-file
• https://unix.stackexchange.com/questions/68523/find-and-remove-large-files-that-are-open-but-have-been-deleted
• https://www.akadia.com/services/lsof_quickstart.txt

[atc0005]

If it's reasonable, we should also list the space consumed by the process as an indicator of how severe the issue is. It may even be useful to support threshold flags to filter out smaller consumption values (i.e., tell me about an unlinked process consuming GB of space, but not an unlinked process consuming only a handful of MB).