From: Stefan Beller <stefanbeller@gmail.com>
To: Junio C Hamano <gitster@pobox.com>, Stefan Beller <sbeller@google.com>
Cc: git@vger.kernel.org, Loic Dachary <loic@dachary.org>
Subject: Re: git update-ref --stdin : too many open files
Date: Mon, 22 Dec 2014 18:41:47 -0800 [thread overview]
Message-ID: <5498D66B.5090807@gmail.com> (raw)
In-Reply-To: <xmqqoaqv8jmi.fsf@gitster.dls.corp.google.com>
On 22.12.2014 13:22, Junio C Hamano wrote:
> Loic Dachary <loic@dachary.org> writes:
>
>> Hi,
>>
>> Steps to reproduce:
>>
>> $ git --version
>> git version 1.9.1
>> $ wc -l /tmp/1
>> 9090 /tmp/1
>> $ head /tmp/1
>> delete refs/pull/1/head
>> create refs/heads/pull/1 86b715f346e52920ca7c9dfe65424eb9946ebd61
>> delete refs/pull/1/merge
>> create refs/merges/1 c0633abdc5311354c9729374e0ba25c97a89f69e
>> ...
>> $ ulimit -n
>> 1024
>> $ git update-ref --stdin < /tmp/1
>> fatal: Unable to create
>> /home/gitmirror/repositories/Ceph/ceph/refs/heads/pull/1917.lock': Too
>> many open files
>> $ head -20 /tmp/1 | git update-ref --stdin
>> $ echo $?
>> 0
>>
>> The workaround is to increase ulimit -n
>>
>> git update-ref --stdin should probably close some files.
>>
>> Cheers
>
> Sounds like the recent "ref update in a transaction" issue to me.
>
> Stefan, want to take a look? I think we do need to keep the .lock
> files without renaming while in transaction, but we do not have to
> keep them open, so I suspect that a fix may be to split the commit
> function into two (one to close but not rename, the other to
> finalize by renaming) or something.
Sounds reasonable. Though by closing the file we're giving up again a
bit of safety. If we close the file everyone could tamper with the lock
file. (Sure they are not supposed to touch it, but they could)
>
> Also the version of transaction series we have queued seem to lock
> these refs very late in the process, but as we discussed privately
> a few weeks ago, we would want to move the lock much earlier, when
> the first update is attempted.
I'll look into that tomorrow.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2014-12-23 2:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-20 10:24 git update-ref --stdin : too many open files Loic Dachary
2014-12-22 21:22 ` Junio C Hamano
2014-12-23 2:41 ` Stefan Beller [this message]
2014-12-23 3:22 ` Jonathan Nieder
2014-12-23 15:57 ` Junio C Hamano
2014-12-24 2:11 ` Stefan Beller
2014-12-29 1:28 ` Michael Haggerty
2014-12-29 22:56 ` Stefan Beller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5498D66B.5090807@gmail.com \
--to=stefanbeller@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=loic@dachary.org \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.