Experience of centralized workflow with NFS-mounted storage?

[Vincent Ladeuil]

>>>>> "Russel" == Russel Winder <russel.winder at concertant.com> writes:

    Russel> On Thu, 2008-11-20 at 16:33 -0600, John Arbash Meinel wrote:
    >> I will say that having your working trees on NFS is often a bad deal
    >> anyway. When I tested that sort of thing in the past, it meant much
    >> longer compile times, etc. So having your repo on NFS and your WT on
    >> local disk is a big win for more than just bzr.
    >> 
    >> 
    >> Also, we *would* like to get rid of the need for an OS lock, it was
    >> meant to allow an optimization that we never got to. It just hasn't been
    >> a high priority versus the other things we've worked on. But if someone
    >> is on NFS and being bitten by not having OS locks, we could certainly
    >> help them work up a patch for a new WT format that doesn't require an OS
    >> lock. (WT3 doesn't require OS locks, but is generally a lot slower than
    >> WT4.)

    Russel> I don't have anything specific about problems (other than using NFS
    Russel> always makes things slower), I just wanted to point out that using NFS
    Russel> for $HOME and having repositories in a subdirectory of $HOME with
    Russel> working trees is surely a standard situation -- it is the whole point of
    Russel> NFS that this is what is going to happen.

    Russel> It worries me that this situation is being treated as second class
    Russel> citizen by Bazaar.


    Russel> Comments such as the above appear to bear out this
    Russel> discrimination against NFS based usage :-(

I think the core of John's remark here is about latency making
NFS slow, not about some reason to *not* support it.


   bzr works for me on NFS without restrictions


Anytime I use virtual machines (and I use them a lot, like 99% of
the time), I use NFS to share the files with the host
machine. That means that 99% of my bzr commands run on NFS for
branches, repositories and working trees.

In the last 3 years I only had a single problem with NFS. A
repository was corrupted. That was with a knit repository...and
almost certainly involved hard crashing a VM. And I could never
reproduced the problem no matter how hard I tried. And the pack
format makes the problem an order of magnitude less likely to
occur again.

And I'm known to run the full bzr test suite quite often and
under various OSes (Ubuntu, OSX, Solaris 2.10 (in the past), Open
Solaris (since a few days).

Servers used include OSX 10.4, OSX 10.5, Festy, Gutsy and Hardy.
Clients used include OSX 10.4, OSX 10.5, Festy, Gutsy, Hardy,
Solaris 2.10 and OpenSolaris 08.11.

NFS versions used, well, things are less clear here as some
negotiations occur generally at mount time, but at least v2 and
v3 *were* used in the past and I'm pretty sure I *now* use v4.

I also used some options at export/mount time in the past (sorry
I didn't take notes :-/) but I don't anymore.

So my best guess is that people experiencing problems with NFS
have... a different setup than me :-/

What difference ? I can't say. All I know is that the only
special thing I do is being careful when I install machines to
create users with the right UIDs which is not always easy, but I
don't think there is anything related to the problem encountered by
others in that setup.

I used to specify the mounts in /etc/fstab but have since
switched to auto_mount so it's all default options there... and
everything work like a charm.

AIUI, it is possible to *not* use locks on NFS... but then, well,
why ?

Oh, and I also use NFS between hosts or between VM on different
hosts (just to rule out special cases in host/guest
relationship).

        Vincent

P.S.: Off-topic: I also used sshfs regularly before going the
full-NFS route in configurations where UIDs weren't matching.