From owner-freebsd-fs@freebsd.org Mon May 9 20:04:10 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 3FCDDB3408C for ; Mon, 9 May 2016 20:04:10 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D08A6131F; Mon, 9 May 2016 20:04:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) IronPort-PHdr: 9a23:VCItMh+dIQrDT/9uRHKM819IXTAuvvDOBiVQ1KB91OMcTK2v8tzYMVDF4r011RmSDdSdsqgP0rGJ+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuSt+U1p78jrvts7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cYk7sb+sVBSaT3ebgjBfwdVWx+cjN92Mq+nwPSRA3HymERTWgMg1IcCQTf4Q73RIbZnDH3u8BG9G+dJ8KgHp4uXjH31aZgS1fNgSwEMzM8uDXNj8V7j6ZWpTq8oBNizorMYMeePawtLevmYdoGSD8ZDY5qXCtbD9b5NtNXAg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CtBADN7DBX/61jaINdhA19BrkegXYXC4UkSgKBchMBAQEBAQEBAWQngi2CFAEBAQMBAQEBICsgCwULAgEIDgoCAg0ZAgInAQkmAgQIBwQBHASIAggOrj2QbwEBAQEBAQEDAQEBAQEBAQEUBHyFJIF+gk6EIgEBgxuCWQWNXopEhX2FMZIFjzkCIgE/ggUbgWcgMgeHQQkXBBt/AQEB X-IronPort-AV: E=Sophos;i="5.24,601,1454994000"; d="scan'208";a="282483673" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-annu.net.uoguelph.ca with ESMTP; 09 May 2016 16:04:07 -0400 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id 6BE5D15F58C; Mon, 9 May 2016 16:04:07 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id pB-v1sAszYHH; Mon, 9 May 2016 16:04:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id D872815F58D; Mon, 9 May 2016 16:04:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7qQ_UVCRIKea; Mon, 9 May 2016 16:04:06 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id C051B15F58C; Mon, 9 May 2016 16:04:06 -0400 (EDT) Date: Mon, 9 May 2016 16:04:06 -0400 (EDT) From: Rick Macklem To: Bryan Drewery Cc: freebsd-fs@freebsd.org Message-ID: <11118918.93955875.1462824246725.JavaMail.zimbra@uoguelph.ca> In-Reply-To: References: Subject: Re: NFS inuse vnode sillyrename with > 1 links MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF46 (Win)/8.0.9_GA_6191) Thread-Topic: NFS inuse vnode sillyrename with > 1 links Thread-Index: 1p9B1EZQSzWBIWONWsQBAI1ulZmTPw== 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 20:04:10 -0000 Bryan Drewery wrote: > 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. Unfortunately, NFS is not (and cannot be) a POSIX compliant file system since it does not have a POSIX open. As such, certain POSIX behaviour cannot "just work". The "silly rename" trick is an attempt to more closely approximate POSIX behaviour, but it cannot always work. The discussion under the phabricator review (especially jhb@'s recent comment) I believe does cover how modifying the "silly rename trick" could break other cases. I noted in the phabricator discussion that I did not know if this change should be done or not. I did express concern, since the current (without this patch) semantic has been in place for over 20years (probably close to 30years) and a change in semantics might result in a POLA violation. It may be preferable to come up with a patch for FTS, if your use case can be fixed that way. rick > 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. > > -- > Regards, > Bryan Drewery > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >