Experience of centralized workflow with NFS-mounted storage?

[Jason Earl]

John Arbash Meinel <john at arbash-meinel.com> writes:

> ...
>
>>> 1) We only use OS locks for *working trees*. So if you have a repository
>>> + branches on NFS everything should work fine. What tends to break is
>>> when your home directory is an NFS directory, because we use an OS lock
>>> on one of the files there (.bzr/checkout/dirstate).
>> 
>> Home directories will be local.
>
> Sounds like as long as you go with only a shared repository + branches
> on the NFS mount (without working trees) then there should be nothing
> that *I've* heard of that would be a problem.
>
> Especially with the current .pack format, we write out data to new
> files, and don't modify existing ones, so problems with the NFS server
> giving garbage, etc should not be a problem.

For the record, I've been doing a bit of testing with working trees on
an NFS mounted partition, and at least in my setup actions such as
merge and clone are actually faster with NFS mounted repositories than
on the local disk.  This despite the fact that the NFS server I was
testing against has hundreds of active users and a load average
consistently over 1.

The difference isn't great.  Cloning the "trunk" of my Emacs bzr test
repository takes an average of 2 minutes 48 seconds on the NFS share and
3 minutes 5 seconds on the local disk.  Merging showed a similar slight
advantage for NFS.  Removing the tree was another story, the repository
on the NFS mount took nearly twice as long to rm the directory.

The difference in speed is even greater when the "local" disk is the
slow one in my laptop.

I'm not saying that it isn't possible to have a pathologically bad NFS
server with problems that are exacerbated by the way bzr works, but I
don't think that it is fair to say that bzr doesn't work well with
NFS-mounted home drives.  It works fine here.  Until I read this thread
I didn't even know that there was a problem, and I routinely use
repositories mounted on an NFS share.

Jason