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

[Alan Somers]

On Fri, Mar 15, 2019 at 9:19 AM Konstantin Belousov <kostikbel at gmail.com> wrote:
>
> 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.

Ok, so the man page is talking files which were formerly open but
deleted, but are no longer open.  I find the wording confusing.  It
seems to refer to files that are still open but deleted.

-Alan