From owner-freebsd-fs@freebsd.org Mon May 9 17:15:31 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19564B3482F for ; Mon, 9 May 2016 17:15:31 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0AF4D119C for ; Mon, 9 May 2016 17:15:31 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 04D7C1629 for ; Mon, 9 May 2016 17:15:31 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id B03881CB7B for ; Mon, 9 May 2016 17:15:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id tGgX4A_VopFu for ; Mon, 9 May 2016 17:15:28 +0000 (UTC) To: freebsd-fs@freebsd.org DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 23F221CB76 From: Bryan Drewery Subject: NFS inuse vnode sillyrename with > 1 links Organization: FreeBSD Message-ID: Date: Mon, 9 May 2016 10:15:27 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 17:15:31 -0000 The context for this is in https://reviews.freebsd.org/D6254 with some discussion already. First my use-case: cd some_nfs_dir/ mkdir src dst touch src/foo ln src/foo dst/foo tail -F dst/foo & rm -rf src/ This fails in rm/FTS (Directory not empty) in rmdir(1) since the removal of src/foo renames it to src/.nfs*. Then FTS tries to rmdir not realizing there is a new file. My real use-case is building Python in a temporary directory, hardlinking it into a staging directory (for running from without polluting /). I then run the staging version of python for the rest of the build. If I try to rebuild Python while something else is running the hard-linked Python from the staging directory then the Python build fails since it is trying to rm -Rf a directory that just got a silly rename, even though I was executing a different named link. I understand that a vnode inuse count is on the vnode and not the name, but in this case I expect rm -Rf to just work since I wasn't running the link being deleted. Implementation complexities and history aside, this should just work, even if it means a hack to FTS/rm rather than nfs_remove. It makes no sense from a user-perspective and has no sane workaround except to not hardlink or use userland r/w locking to avoid removing a binary in-use. So to NFS. I know nothing about the protocol or history. I just know that in this case it seems fine to not do a silly rename on a file if it has multiple links, since the vnode will still be around to be used by the kernel for in-use consumers. --=20 Regards, Bryan Drewery