For a variety of reasons, NFS is not a reliable file system protocol. There
are some places where it slightly alters the semantics of files for
efficiency, and one of these is in consistency issues. In particular, NFS
allows client-side caches and (in it's original form) did not provide a
Successive versions of NFS have become closer to reliable, but the
additional communication and synchronization traffic tends to slow things
down (a lot) and people therefore tend to disable these features.
Perhaps someone more up to date on later versions of NFS can shed light on
the current state of things, but my general view is that one should not
publish mission critical data on an NFS partition.
Quite apart from NFS, but interacting with it, be advised that an awful lot
of servers out there have the EtherExpress network chip (Intel design, sucks
donkeys). Under conditions of heavy *disk* I/O load (and probably other high
I/O conditions, but I/O reliably causes problems), the EtherExpress locks
up. While the very latest drivers will reset it, the lockup remains in place
long enough to cause NFS timeouts (thus the connection to the NFS thread).
I'm told that this is not a problem for OpenBSD, but it's definitely an
issue for Linux.
I am puzzled, however. Given that client/server has been part of the SVN
design from the first, why not just use SVN in client/server mode and run
the server on your central machine?
----- Original Message -----
From: "Brian Behlendorf" <firstname.lastname@example.org>
Sent: Monday, September 11, 2000 5:37 PM
Subject: Re: CVS update: subversion/subversion/include svn_fs.h
> On 9 Sep 2000, Jim Blandy wrote:
> > Berkeley DB is unable to promise its transaction semantics if the
> > database is accessed via NFS.
> Ouch - does that imply that Subversion won't be able to function properly
> on NFS? It's a requirement for us since we will be using centralized
> storage all over the place, except for extreme low latency needs like mail
Received on Sat Oct 21 14:36:08 2006