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

> 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