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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).