From: Martin Fick <mfick@codeaurora.org>
To: David Turner <novalis@novalis.org>
Cc: Jacob Keller <jacob.keller@gmail.com>,
Git mailing list <git@vger.kernel.org>,
Christian Couder <christian.couder@gmail.com>
Subject: Re: Simultaneous gc and repack
Date: Thu, 13 Apr 2017 12:36:20 -0600 [thread overview]
Message-ID: <1553777.vJallt5N6j@mfick1-lnx> (raw)
In-Reply-To: <1492108087.1527.82.camel@novalis.org>
On Thursday, April 13, 2017 02:28:07 PM David Turner wrote:
> On Thu, 2017-04-13 at 12:08 -0600, Martin Fick wrote:
> > On Thursday, April 13, 2017 11:03:14 AM Jacob Keller
wrote:
> > > On Thu, Apr 13, 2017 at 10:31 AM, David Turner
> >
> > <novalis@novalis.org> wrote:
> > > > Git gc locks the repository (using a gc.pid file) so
> > > > that other gcs don't run concurrently. But git
> > > > repack
> > > > doesn't respect this lock, so it's possible to have
> > > > a
> > > > repack running at the same time as a gc. This makes
> > > > the gc sad when its packs are deleted out from under
> > > > it
> > > > with: "fatal: ./objects/pack/pack-$sha.pack cannot
> > > > be
> > > > accessed". Then it dies, leaving a large temp file
> > > > hanging around.
> > > >
> > > > Does the following seem reasonable?
> > > >
> > > > 1. Make git repack, by default, check for a gc.pid
> > > > file
> > > > (using the same logic as git gc itself does).
> > > > 2. Provide a --force option to git repack to ignore
> > > > said
> > > > check. 3. Make git gc provide that --force option
> > > > when
> > > > it calls repack under its own lock.
> > >
> > > What about just making the code that calls repack
> > > today
> > > just call gc instead? I guess it's more work if you
> > > don't
> > > strictly need it but..?
> >
> > There are many scanerios where this does not achieve
> > the
> > same thing. On the obvious side, gc does more than
> > repacking, but on the other side, repacking has many
> > switches that are not available via gc.
> >
> > Would it make more sense to move the lock to repack
> > instead of to gc?
>
> Other gc operations might step on each other too (e.g.
> packing refs). That would be less bad (and less common),
> but it still seems worth avoiding.
Yes, but all of thsoe operations need to be self protected
already, or they risk the same issue.
-Martin
--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2017-04-13 18:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-13 17:31 Simultaneous gc and repack David Turner
2017-04-13 18:03 ` Jacob Keller
2017-04-13 18:08 ` Martin Fick
2017-04-13 18:28 ` David Turner
2017-04-13 18:35 ` Jacob Keller
2017-04-13 18:36 ` Martin Fick [this message]
2017-04-13 19:05 ` David Turner
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=1553777.vJallt5N6j@mfick1-lnx \
--to=mfick@codeaurora.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=jacob.keller@gmail.com \
--cc=novalis@novalis.org \
/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).