On 03/29/14 08:06, Philip Guenther wrote:
On Wed, Mar 26, 2014 at 7:50 AM, Mike Belopuhov <m...@belopuhov.com> wrote:
After a bunch of failures (ld.so can't find libc.so for the install(1))
with parallel make build (-j 4) on an NFS setup I came up with this
simple testcase that shows that rename(2) on NFS is not atomic by
trying to open(2) the file that is being renamed in a tight loop.
I can reproduce this on v2 and v3 mounts served by 5.1 as well as
local v2 and v3 mounts on 5.1 and -current.
This is a bug in our NFS client code: we don't do vnode locking in our
NFS client.
What is happening is that program 1 does a rename of the target file
while program 2 has it open.
To maintain UNIX open file semantics, the nfs client rename code does
a "sillyrename" to the target file out of the way first, before
renaming the source to the target; that two step process introduces a
window where the target doesn't exist.
If we had vnode locking in our NFS client, the rename by program 1
would lock (on the client) the target directory from the sillyrename
to the final rename and program 1 would thus be unable to win the race
and see the file as non-existent.
(An alternative would be for rename to do a "sillyhardlink" instead of
a "sillyrename", but that makes assumptions about NFS servers that
might not be safe. Maybe. And it doesn't completely solve the
semantics problem anyway.)
As for why our NFS client doesn't do vnode locking, I'll defer to
tedu, beck, and theo, as I wasn't around for that...
Philip Guenther
Come on, Philip. Take a look at it. It can't hurt, can it...? ;-)
/Alexander
