cvs commit: src/sys/kern vfs_syscalls.c

[Joerg Sonnenberger]

On Wed, Aug 17, 2005 at 10:30:22AM -0700, Matthew Dillon wrote:
> 
> :...
> :the standard differenciates between files (UFS: inode) and directory
> :entries.
> :
> :>     It's simple and straightfoward, not ultra complex.  It is not
> :>     rename's responsibility to validate or resolve symlinks, or to
> :>     treat hardlinks as a special case.  rename is entirely a namespace
> :>     operation.  The only requirements are that it disallow impossible
> :>     combinations, such as trying to rename a file over a directory,
> :>     or rename a directory into a sub-directory of itself.
> :
> :As soon as the "new" operand already exists it is not a pure namespace
> :operation anymore. What happens if two NFS clients have the directory
> :cached, the first issues "mv a b", the second "mv b a"? Are both clients
> :issuing remove operations with the new code?
> :
> :Joerg
> 
>     No, they aren't.  Don't forget that all VFS operations have some sort
>     of locking.  In the case of DragonFly, the namespace itself is locked
>     so a simultanious back-and-forth rename can't happen.

How do you look at the namespace of the NFS server? Let me extend the
example a bit to make more clean what I mean.

HOSTA serves /test via NFS. /test/a and /test/b are hardlinks to the same
file. HOSTB and HOSTC have HOSTA:/test mounted as /test.

HOSTB issues mv /test/a /test/b, HOSTC issues mv /test/b /test/a. At
which part of the operation is the NFS server involved? I can see two
points: during lookup of a and b and after kern_rename decided what
operation to issue (rename or remove). IMO the latter two can race against
each other.

Joerg