[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS and NFS: Questions
Re: CVS and NFS: Questions
Thu, 9 Oct 2003 19:25:42 -0400 (EDT)
Derek Robert Price writes [about NFS-mounted repositories]:
> Many of the issues are related to locking.
No, they're not. We've never had a report of a problem related to
locking on NFS.
> CVS uses a successful
> mkdir(lockdir) to prevent other processes from creating locks. As I
> understand it, caching issues in NFS clients can cause two processes to
> receive success codes from the mkdir call at the same time even though
> one of them fails on the server end. The two processes can then happily
> start writing the same archive files, causing corruption.
No. NFS guarantees that mkdir() is an atomic operation, so it can't be
cached and two clients can't both get a successful return. The one
theoretical problem is that mkdir() isn't idempotent (you can't do it
twice and get the same result both times). If the client succesfully
creates the directory but the response from the NFS server gets lost,
the client will retry the mkdir() which will then fail. In this case,
the client has created the lock but thinks that someone else has. This
orphan lock will never be removed by CVS and thus prevents anyone from
locking the directory, but it does not allow corruption. It has also
never been reported in practice.
> I'm uncertain
> whether this is an issue when only a single NFS client has mounted the
> NFS server. Regardless, you can work around this problem by setting the
> LockDir= option in CVSROOT/config to point to a locally mounted
> directory provided all the CVS clients are running on the same machine.
That's a very important proviso. I would strongly recommend against it
unless you have the NFS server configured so that the filesystem can't
possibly be mounted on any other machine.
> The other NFS issues that frequently arise are much more troublesome.
> Apparently, especially with non-homogenous NFS implementations,
> interoperability problems can cause random NUL bytes in the
> communication stream to be written to the archive files. This is
> trouble and there is no workaround available. This is why NFS is
> usually discouraged for use with CVS.
This is the real problem. In all the cases I've seen, there are one or
more blocks of NULs in the RCS files instead of the legitimate data,
implying that those blocks were never written by the NFS server. Both
the client and server have been used successfully with other servers and
clients, so it isn't clear whether the real problem is in the client,
the server, or both. As far as I know, no one has isolated the problem,
but it isn't unique to CVS: at least one of my company's CAD packages
has encountered exactly the same problem.
The problem with the future is that it keeps turning into the present.