git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: gc does not clean up after itself when not enough disk space

From
Jeff King <peff@peff.net>
Date
Feb 27, 2013, 05:07 UTC
Message-ID
<20130227050735.GA10976@sigill.intra.peff.net>
In-Reply-To
<CAMK1S_hxZZzi911s2QRpc67sNf_U7Ceo1fPT_hg1gO500pO=6A@mail.gmail.com>
On Wed, Feb 27, 2013 at 05:58:20AM +0530, Sitaram Chamarty wrote:
Show 9 quoted lines
> > Ack. I just recently had to do
> >
> >    git gc || rm -f .git/objects/*/tmp_*
> >
> > as workaround in the nightly housekeeping script on our CI server.
> 
> it's not just 'git gc'; a failed push of a large repo (failed due to,
> say, network issues or whatever) also leave tmp_* lying around.  At
> least as far as I can tell...

Yes, we used to run into problems with failed pushes sometimes at GitHub. A later `git gc` will clean up the tmp_* objects (via `git prune`), but of course we will not run the prune if the repack fails. Also note that a push will just keep receiving objects as long as the client wishes to send them, spooling straight to disk, before any enforcement hooks have a chance to run. So on stock git, you could in theory just fill up the receiver's disk, and then git will leave the file sitting around.

I have a patch to make index-pack just do a hard hangup after receiving `receive.maximumBytes` bytes (with an appropriate message to stderr). It's not an exact measure of the size of the push (since we need to complete thin packs, and we may also explode smaller packs), but it at least bounds the size that the sender can push. I'm happy to share the patch if others are interested (it's only a few lines).

I've also considered a patch to have index-pack clean up tmp_pack_* automatically on exit, default to off (i.e., the current behavior). A busy site could turn it on globally, and then shut it off for a specific repo when trying to debug a push problem. I find that the leftover tmp_pack files are very seldom of interest for forensic debugging. I haven't bothered to write that patch, though; we dropped our prune expiration time well below the 2-week default, so the tmp files get cleaned up pretty regularly now.

-Peff
Previous: Sitaram Chamarty
Message 5 of 5 in “gc does not clean up after itself when not enough disk space”
  1. jones.noamleFeb 26, 2013
  2. Junio C HamanoFeb 26, 2013
  3. Jens LehmannFeb 26, 2013
  4. Sitaram ChamartyFeb 27, 2013
  5. Jeff KingFeb 27, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.