Re: what's the current wisdom on git over NFS/CIFS?

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 2, 2009, 20:58 UTC
Message-ID: <alpine.LFD.2.01.0907021345440.3210@localhost.localdomain>
In-Reply-To: <slrnh4pcf8.484.sitaramc@sitaramc.homelinux.net>

On Thu, 2 Jul 2009, Sitaram Chamarty wrote:

Show 5 quoted lines

> 
> A couple of us were beating each other senseless on this
> issue over on #git, so I thought I'd ask: is it OK to do
> this?  Or would there potential be race conditions due to
> the lack of proper locking?

It should all work fine.

We've had a few NFS issues due to oddities with renaming across directories, but modern git avoids the cross-directory renames, and that whole issue only hit some very specific cases anyway.

And git doesn't have "proper locking", because it doesn't need it for database ops: git objects are stable. For refs, git should be using the proper NFS-safe "create and atomic rename" ops.

You do need to be a bit careful if you do maintenance operations concurrently (I would suggest avoiding doing concurrent "git gc --prune", for example), but any normal git workflow should be fine.

There is one big thing to look out for: performance. You may want to add

	[core]
		PreloadIndex = true

in your .git/config file, especially if you have a high-latency NFS server (but if you have a fast network and a high-end NFS server, you might be better off without it, so do your own testing).

Btw, I think we fixed the problem we had with CIFS. That one was a cifs filesystem problem on Linux, but it should be fixed in 2.6.30+ (commit 0f4d634c: "cifs: flush data on any setattr"). If you have an older kernel (or are just uncertain), you can also work around it with

	[core]
		fsyncobjectfiles = true

which may be a good thing in general (regardless of any cifs issues), but in most cases the performance loss isn't worth it if your filesystem is stable and sane.

			Linus