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

[Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>]

On Thu, 2 Jul 2009, Sitaram Chamarty wrote:
> 
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html