VOP_INACTIVE(9): reclaiming space for open but deleted files?

[Konstantin Belousov]

On Fri, Mar 15, 2019 at 08:44:57AM -0600, Alan Somers wrote:
> VOP_INACTIVE(9) says that the vop can "be used to reclaim space for
> ‘open but deleted’ files".  What does that mean?  How can you reclaim
> space for open files?  I assume it's just a mistake, but I want to
> check before I fix the man page.  SVN archaeology shows that the line
> has been present since a mass import of man pages in 1997.

VOP_INACTIVE() call means that the last use count for the vnode is
dereferenced. This can only happen when there is no more open files
using the vnode.

Now consider what happens when you open file, then unlink it while
keeping the file opened. Filesystems usually mark such files with
VV_NOSYNC v_vflag, but there are typically other means to determine that
there is no name for the inode, like UFS i_nlink. On the last close
VOP_INACTIVE() is called (this is not guaranteed but you need to race to
not get the call). Then, if the vnode is not reclaimed, it is put on the
free list and the allocated blocks and other resources linger until the
vnode is reclaim (reclaim absolutely must free space for inodes which
cannot be reached).  If inactive() frees the resources, the temporal
leak is avoided.

As example look at UFS_INACTIVE().  If it detects file with effective link
count of zero, it resets i_mode and calls ffs_vfree() to free inode.  Then
the vnode is reclaimed.