{"thread":{"id":"34121","subject":"slow process of post-receive script on a remote (samba) share","startedAt":"2013-06-13T09:18:32Z","lastAt":"2013-06-14T13:06:46Z","messageCount":5,"participants":["Tamas Csabina","Thomas Rast"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"220702","messageId":"CAH+Cn14TLpR1KT+3GND2Zmb8tDmFBP7AWpyrT7nVeMFw6V7FGA@mail.gmail.com","threadId":"34121","inReplyTo":null,"subject":"slow process of post-receive script on a remote (samba) share","fromName":"Tamas Csabina","fromEmail":"tcsabina@gmail.com","sentAt":"2013-06-13T09:18:32Z","receivedAt":"2013-06-13T09:18:32Z","isPatch":false,"sender":{"key":"tcsabina@gmail.com","avatar":null},"body":"Dear list,\n\nI am using Git bash from version 1.8.3.msysgit.0, on a Windows 7x64 PC.\nI have an issue with executing git push if I have a post-receive\nscript configured.\nThe content of the script is not really important, as if I have a\nscript that contains only commented out lines (around 70 lines), my\ngit push command is delayed with around 5 seconds.\n\n\nI`ve tested the script on another PC and it is working fine. No delay\nat all. So there are some issues on my PC regarding how git processes\nremote scripts.\n\nI took a wireshark trace with 2 scenarios on my PC:\n\n 1. just execute `cat \\post-receive` command in the git bash\n 2. did a `real` git push\n\nResults of the wireshark traces shows:\n\n 1. Read AndX Request, FID: 0x228f, 1024 bytes at offset 0 (1024 bytes\nat time, always)\n 2. Read AndX Request, FID: 0x21c9, 1 byte at offset 0 (1 byte, always)\n\nConclusion:\ngit push command reads the post-receive script in 1 byte chunks, which\ndramatically slows down the execution process.\n\n\nIf more information is required about my setup or configuration, I\nwill provided it happily, but I think this 1 byte read is the main\nreason for the issue.\n\nHas anyone seen something similar? Or have any clues what is going on?\n\n\nThanks,\ntamas\n\nps: this is my 3rd (or 4th) attempt to post on the mailing list, using\na different email account this time. If any of the previous attempt\nalso arrived, then sorry for the double posts.\n"},{"id":"220717","messageId":"87li6eqk2a.fsf@linux-k42r.v.cablecom.net","threadId":"34121","inReplyTo":"CAH+Cn14TLpR1KT+3GND2Zmb8tDmFBP7AWpyrT7nVeMFw6V7FGA@mail.gmail.com","subject":"Re: slow process of post-receive script on a remote (samba) share","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-06-13T12:19:57Z","receivedAt":"2013-06-13T12:19:57Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Tamas Csabina writes:\n\n> I am using Git bash from version 1.8.3.msysgit.0, on a Windows 7x64 PC.\n> I have an issue with executing git push if I have a post-receive\n> script configured.\n> The content of the script is not really important, as if I have a\n> script that contains only commented out lines (around 70 lines), my\n> git push command is delayed with around 5 seconds.\n>\n>\n> I`ve tested the script on another PC and it is working fine. No delay\n> at all. So there are some issues on my PC regarding how git processes\n> remote scripts.\n>\n> I took a wireshark trace with 2 scenarios on my PC:\n>\n> 1. just execute `cat \\post-receive` command in the git bash\n> 2. did a `real` git push\n>\n> Results of the wireshark traces shows:\n>\n> 1. Read AndX Request, FID: 0x228f, 1024 bytes at offset 0 (1024 bytes\n> at time, always)\n> 2. Read AndX Request, FID: 0x21c9, 1 byte at offset 0 (1 byte, always)\n>\n> Conclusion:\n> git push command reads the post-receive script in 1 byte chunks, which\n> dramatically slows down the execution process.\n\ngit doesn't read the script; the interpreter does. In the case of a\nscript, the interpreter is specified in the #! line at the top; in the\ncase of a binary executable, it is specified within the executable (and\nfor linux, is usually /lib/ld-linux.so.2).\n\nExactly the same should happen if you run the hook manually, so you can\ntry that to debug it.\n\nNote also that Weird Things(tm) relating to SIGPIPE may happen if you\ndon't read your input. Even if you are only fooling around for testing,\na post-receive hook must consume its input, e.g., by discarding it with\n'cat >/dev/null'.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"220730","messageId":"CAH+Cn14neoV9eXqBAj6_MPXTXK00S=-MnBYs20gaBLZ7YjL00Q@mail.gmail.com","threadId":"34121","inReplyTo":"87li6eqk2a.fsf@linux-k42r.v.cablecom.net","subject":"Re: slow process of post-receive script on a remote (samba) share","fromName":"Tamas Csabina","fromEmail":"tcsabina@gmail.com","sentAt":"2013-06-13T13:47:32Z","receivedAt":"2013-06-13T13:47:32Z","isPatch":false,"sender":{"key":"tcsabina@gmail.com","avatar":null},"body":"Hi Thomas,\n\nThanks for the reply.\nThe script is a bash script, just to mention.\n\nMeanwhile I`ve figured it out that the sluggish post-receive execution\nwas due to a (mis)-configuration in the samba share where the remote\nrepository is hosted. These are:\noplocks = No\nlevel2 oplocks = No\n\nRemoving these from the share`s section in the smb.conf solved the\nissue, and the push process is taking up around 4 seconds, which I\nthink is reliable.\n\n\nNow, do I have to worry about allowing oplocks on the remote\nrepository from the git point of view? Thinking about concurrent push\noperations from different developers?\n\n\nTamas\n\n\nOn 13 June 2013 14:19, Thomas Rast wrote:\n> Tamas Csabina writes:\n>\n>> I am using Git bash from version 1.8.3.msysgit.0, on a Windows 7x64 PC.\n>> I have an issue with executing git push if I have a post-receive\n>> script configured.\n>> The content of the script is not really important, as if I have a\n>> script that contains only commented out lines (around 70 lines), my\n>> git push command is delayed with around 5 seconds.\n>>\n>>\n>> I`ve tested the script on another PC and it is working fine. No delay\n>> at all. So there are some issues on my PC regarding how git processes\n>> remote scripts.\n>>\n>> I took a wireshark trace with 2 scenarios on my PC:\n>>\n>> 1. just execute `cat \\post-receive` command in the git bash\n>> 2. did a `real` git push\n>>\n>> Results of the wireshark traces shows:\n>>\n>> 1. Read AndX Request, FID: 0x228f, 1024 bytes at offset 0 (1024 bytes\n>> at time, always)\n>> 2. Read AndX Request, FID: 0x21c9, 1 byte at offset 0 (1 byte, always)\n>>\n>> Conclusion:\n>> git push command reads the post-receive script in 1 byte chunks, which\n>> dramatically slows down the execution process.\n>\n> git doesn't read the script; the interpreter does. In the case of a\n> script, the interpreter is specified in the #! line at the top; in the\n> case of a binary executable, it is specified within the executable (and\n> for linux, is usually /lib/ld-linux.so.2).\n>\n> Exactly the same should happen if you run the hook manually, so you can\n> try that to debug it.\n>\n> Note also that Weird Things(tm) relating to SIGPIPE may happen if you\n> don't read your input. Even if you are only fooling around for testing,\n> a post-receive hook must consume its input, e.g., by discarding it with\n> 'cat >/dev/null'.\n>\n> --\n> Thomas Rast\n> trast@{inf,student}.ethz.ch\n"},{"id":"220732","messageId":"87txl2jd8k.fsf@linux-k42r.v.cablecom.net","threadId":"34121","inReplyTo":"CAH+Cn14neoV9eXqBAj6_MPXTXK00S=-MnBYs20gaBLZ7YjL00Q@mail.gmail.com","subject":"Re: slow process of post-receive script on a remote (samba) share","fromName":"Thomas Rast","fromEmail":"trast@inf.ethz.ch","sentAt":"2013-06-13T14:29:15Z","receivedAt":"2013-06-13T14:29:15Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Tamas Csabina writes:\n\n> Meanwhile I`ve figured it out that the sluggish post-receive execution\n> was due to a (mis)-configuration in the samba share where the remote\n> repository is hosted. These are:\n> oplocks = No\n> level2 oplocks = No\n[...]\n> Now, do I have to worry about allowing oplocks on the remote\n> repository from the git point of view? Thinking about concurrent push\n> operations from different developers?\n\n>From a brief glance at the relevant docs [1], it would seem that oplocks\nare actually just an implementation detail for safe (in the context of\nparallel access) client caching. So they should be fully transparent to\nany application usage. However, the docs do mention that you may be in\ntrouble if the connection to the server times out.\n\nThat being said, some FSes see more usage and thus have been tested more\nin this context, and git does tend to show some pretty weird issues on\nbroken network FSes (one such case: Lustre[2]).\n\nIn addition, there are some known races w.r.t. the handling of refs, and\nof pruning, if you run git-gc while concurrent pushes are going on.\nJeff King and Michael Haggerty are currently working on getting them\nfixed, see e.g. [3]. To see these, you'll have to hit the repo much\nharder than a small team can.\n\nSo it *should* work, at least if you disable gc.auto and run git-gc\nmanually at some safe time. But I wouldn't be surprised if there are\nbugs lurking in the context of Windows usage on a Samba-hosted repo,\nwhich sounds like a very rare combination.\n\nAnd in any case, don't take my word for it; if your life or company\ndepends on this, you'll need to do your own testing to ensure that it\nholds up.\n\n\nOh, and why do it that way? You would most likely get much better\nperformance out of it if you hosted the repo over ssh (e.g. with\ngitolite[4]) or a smart-http server, since the expensive operations (and\nthey are *expensive*) would be completely local to the server. The\ntradeoff there is that it also shifts a lot of CPU work to the server,\nbut if you can afford it, you should see a great speedup especially when\nfetching large amounts of data (e.g. at cloen time).\n\n\n\n[1] http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html#id2615667\n\n[2] http://thread.gmane.org/gmane.comp.version-control.git/212109\n\n[3] http://thread.gmane.org/gmane.comp.version-control.git/223299\n\n[4] http://gitolite.com/gitolite/\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"220815","messageId":"CAH+Cn15buFMaf8Lp_vAmMBfUFqkctSjFvJ3Z748qf1pLUe-40w@mail.gmail.com","threadId":"34121","inReplyTo":"87txl2jd8k.fsf@linux-k42r.v.cablecom.net","subject":"Re: slow process of post-receive script on a remote (samba) share","fromName":"Tamas Csabina","fromEmail":"tcsabina@gmail.com","sentAt":"2013-06-14T13:06:46Z","receivedAt":"2013-06-14T13:06:46Z","isPatch":false,"sender":{"key":"tcsabina@gmail.com","avatar":null},"body":"Thanks for the follow up ideas.\n\nWe also decided to access the repos through ssh. With that, there is\nno delay at all.\n\n\nRegards,\nTamas\n\n\n\nOn 13 June 2013 16:29, Thomas Rast wrote:\n> Tamas Csabina writes:\n>\n>> Meanwhile I`ve figured it out that the sluggish post-receive execution\n>> was due to a (mis)-configuration in the samba share where the remote\n>> repository is hosted. These are:\n>> oplocks = No\n>> level2 oplocks = No\n> [...]\n>> Now, do I have to worry about allowing oplocks on the remote\n>> repository from the git point of view? Thinking about concurrent push\n>> operations from different developers?\n>\n> From a brief glance at the relevant docs [1], it would seem that oplocks\n> are actually just an implementation detail for safe (in the context of\n> parallel access) client caching. So they should be fully transparent to\n> any application usage. However, the docs do mention that you may be in\n> trouble if the connection to the server times out.\n>\n> That being said, some FSes see more usage and thus have been tested more\n> in this context, and git does tend to show some pretty weird issues on\n> broken network FSes (one such case: Lustre[2]).\n>\n> In addition, there are some known races w.r.t. the handling of refs, and\n> of pruning, if you run git-gc while concurrent pushes are going on.\n> Jeff King and Michael Haggerty are currently working on getting them\n> fixed, see e.g. [3]. To see these, you'll have to hit the repo much\n> harder than a small team can.\n>\n> So it *should* work, at least if you disable gc.auto and run git-gc\n> manually at some safe time. But I wouldn't be surprised if there are\n> bugs lurking in the context of Windows usage on a Samba-hosted repo,\n> which sounds like a very rare combination.\n>\n> And in any case, don't take my word for it; if your life or company\n> depends on this, you'll need to do your own testing to ensure that it\n> holds up.\n>\n>\n> Oh, and why do it that way? You would most likely get much better\n> performance out of it if you hosted the repo over ssh (e.g. with\n> gitolite[4]) or a smart-http server, since the expensive operations (and\n> they are *expensive*) would be completely local to the server. The\n> tradeoff there is that it also shifts a lot of CPU work to the server,\n> but if you can afford it, you should see a great speedup especially when\n> fetching large amounts of data (e.g. at cloen time).\n>\n>\n>\n> [1] http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html#id2615667\n>\n> [2] http://thread.gmane.org/gmane.comp.version-control.git/212109\n>\n> [3] http://thread.gmane.org/gmane.comp.version-control.git/223299\n>\n> [4] http://gitolite.com/gitolite/\n>\n> --\n> Thomas Rast\n> trast@{inf,student}.ethz.ch\n"}]}