Date: Mon, 9 May 2016 16:04:06 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Bryan Drewery <bdrewery@FreeBSD.org> Cc: freebsd-fs@freebsd.org Subject: Re: NFS inuse vnode sillyrename with > 1 links Message-ID: <11118918.93955875.1462824246725.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <b8a07958-85c1-2915-e33b-fbe14d54d2eb@FreeBSD.org> References: <b8a07958-85c1-2915-e33b-fbe14d54d2eb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11118918.93955875.1462824246725.JavaMail.zimbra>