Re: slow process of post-receive script on a remote (samba) share

From: Thomas Rast <trast@inf.ethz.ch>
Date: Jun 13, 2013, 14:29 UTC
Message-ID: <87txl2jd8k.fsf@linux-k42r.v.cablecom.net>
In-Reply-To: <CAH+Cn14neoV9eXqBAj6_MPXTXK00S=-MnBYs20gaBLZ7YjL00Q@mail.gmail.com>

Tamas Csabina <tcsabina@gmail.com> writes:

Show 5 quoted lines

> Meanwhile I`ve figured it out that the sluggish post-receive execution
> was due to a (mis)-configuration in the samba share where the remote
> repository is hosted. These are:
> oplocks = No
> level2 oplocks = No

[...]

> Now, do I have to worry about allowing oplocks on the remote
> repository from the git point of view? Thinking about concurrent push
> operations from different developers?

>From a brief glance at the relevant docs [1], it would seem that oplocks

are actually just an implementation detail for safe (in the context of parallel access) client caching. So they should be fully transparent to any application usage. However, the docs do mention that you may be in trouble if the connection to the server times out.

That being said, some FSes see more usage and thus have been tested more in this context, and git does tend to show some pretty weird issues on broken network FSes (one such case: Lustre[2]).

In addition, there are some known races w.r.t. the handling of refs, and of pruning, if you run git-gc while concurrent pushes are going on. Jeff King and Michael Haggerty are currently working on getting them fixed, see e.g. [3]. To see these, you'll have to hit the repo much harder than a small team can.

So it *should* work, at least if you disable gc.auto and run git-gc manually at some safe time. But I wouldn't be surprised if there are bugs lurking in the context of Windows usage on a Samba-hosted repo, which sounds like a very rare combination.

And in any case, don't take my word for it; if your life or company depends on this, you'll need to do your own testing to ensure that it holds up.

Oh, and why do it that way? You would most likely get much better performance out of it if you hosted the repo over ssh (e.g. with gitolite[4]) or a smart-http server, since the expensive operations (and they are *expensive*) would be completely local to the server. The tradeoff there is that it also shifts a lot of CPU work to the server, but if you can afford it, you should see a great speedup especially when fetching large amounts of data (e.g. at cloen time).

[1]  http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html#id2615667

[2]  http://thread.gmane.org/gmane.comp.version-control.git/212109

[3]  http://thread.gmane.org/gmane.comp.version-control.git/223299

[4]  http://gitolite.com/gitolite/

-- 
Thomas Rast
trast@{inf,student}.ethz.ch