On Thu, Jun 09, 2011 at 04:32:26PM +0200, Markus Schaber wrote:
> Hi,
>
> > Von: Stefan Sperling [mailto:stsp_at_elego.de]
>
> > If your Apache server is handling requests via threads (rather than
> > forking
> > processes) this might explain why you never saw this problem with just
> > dav.
> > The threads can synchronise via mutexes which live in the same process
> > address space. But separate processes require file locking for proper
> > synchronisation.
>
> If there's only one machine running the Apache server, and the svnserve
> is on a different one, then another hint may be that the apache machine
> locked the files locally but not on the NFS server, so it worked fine in
> the one-machine case. AFAIR some NFS clients had that behavior that
> locks were respected locally, even if they were not propagated to the
> server.
Yes, I've seen examples of this.
Problems can happen either because one side doesn't support locks,
or because the lock tokens used are not compatible.
I've seen problems with incompatible lock tokens between Linux and
FreeBSD machines some years ago. Both support locking but it wasn't
interoperable when I tried. This might since have been fixed (hopefully).
I've also seen NFS clients that do not support sending lock tockens to
the server but still present locks to local processes accessing the
NFS-mounted filesystem. E.g. OpenBSD NFS clients behave like this and
do not support sending locks to the server. But an OpenBSD server
supports locking for clients which do support it, but I'm not sure
what clients this is compatible with.
In general, exposing FSFS repositories over NFS should only be done
if file locking is supported and the locking implementations of
NFS client and server are known to be fully interoperable.
Received on 2011-06-09 16:56:39 CEST