Date: Fri, 15 Mar 2019 17:19:20 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alan Somers <asomers@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: VOP_INACTIVE(9): reclaiming space for open but deleted files? Message-ID: <20190315151920.GC96870@kib.kiev.ua> In-Reply-To: <CAOtMX2iz%2BN6Esk2yzoeo-5_WxH2aF4LvvtumTWmGWdYiXZtZtA@mail.gmail.com> References: <CAOtMX2iz%2BN6Esk2yzoeo-5_WxH2aF4LvvtumTWmGWdYiXZtZtA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190315151920.GC96870>