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

[Thomas Rast <trast@inf.ethz.ch>]

Tamas Csabina <tcsabina@gmail.com> writes:

> 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