At GitHub we were seeing occasional lock contention over packed-refs.
It wasn't very common, but when you have as much git traffic as we
have, anything that *can* happen *will* happen.
The problem is that Git only tries to acquire locks a single time. If
that attempt fails, the whole process fails. So, for example, if two
processes are trying to delete two different references, one of them
can fail due to inability to acquire the packed-refs lock, even though
it could have succeeded if it had just waited a moment.
This patch series adds a new function,
hold_lock_file_for_update_timeout(), which retries the lock
acquisition for a specified length of time. The retries necessarily
have to use polling, which it does using a quadratic backoff with a
random component. It might be a bit overengineered for this single
purpose, but I wanted it to be usable in other contexts without second
thoughts.
This patch series also changes lock_packed_refs() to call the new
function with a timeout of 1 second (by default; the timeout is
configurable) and adds some tests that the retry and timeout are
working.
It might be that there are other call sites that would benefit from
retrying lock acquisition (the index file?), but this patch series
only applies the new functionality to packed-refs.lock.
We have a patch similar to this one running on our servers at GitHub,
with no problems observed so far.
This series applies to master. It is also available from my GitHub
repository:
https://github.com/mhagger/git branch lockfile-retry
Michael Haggerty (2):
lockfile: allow file locking to be retried with a timeout
lock_packed_refs(): allow retries when acquiring the packed-refs lock
Documentation/config.txt | 6 ++++
lockfile.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++--
lockfile.h | 16 ++++++++--
refs.c | 12 +++++++-
t/t3210-pack-refs.sh | 17 +++++++++++
5 files changed, 125 insertions(+), 5 deletions(-)
--
2.1.4
--
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