From owner-freebsd-hackers@freebsd.org Fri Mar 15 15:19:30 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A0B0154B8FA for ; Fri, 15 Mar 2019 15:19:30 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AC9126C97D; Fri, 15 Mar 2019 15:19:29 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2FFJKZM031795 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Mar 2019 17:19:24 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2FFJKZM031795 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2FFJKbk031794; Fri, 15 Mar 2019 17:19:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 Mar 2019 17:19:20 +0200 From: Konstantin Belousov To: Alan Somers Cc: FreeBSD Hackers Subject: Re: VOP_INACTIVE(9): reclaiming space for open but deleted files? Message-ID: <20190315151920.GC96870@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 15:19:30 -0000 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.