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

Re: git repack leaks disk space on ENOSPC

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Oct 12, 2017, 03:17 UTC
Message-ID
<20171012031702.GB155740@aiede.mtv.corp.google.com>
In-Reply-To
<20171011150546.GC32090@inner.h.apk.li>
Hi Andreas,
Andreas Krey wrote:
> I observed (again) an annoying behavior of 'git repack':

Do you have context for this 'again'? E.g. was this discussed previously on-list?

Show 19 quoted lines
> When the new pack file cannot be fully written because
> the disk gets full beforehand, the tmp_pack file isn't
> deleted, meaning the disk stays full:
>
>   $ df -h .; git repack -ad; df -h .; ls -lart .git/objects/pack/tmp*; rm .git/objects/pack/tmp*; df -h .
>   Filesystem                        Size  Used Avail Use% Mounted on
>   /dev/mapper/vg02-localworkspaces  250G  245G  5.1G  98% /workspaces/calvin
>   Counting objects: 4715349, done.
>   Delta compression using up to 8 threads.
>   Compressing objects: 100% (978051/978051), done.
>   fatal: sha1 file '.git/objects/pack/tmp_pack_xB7DMt' write error: No space left on device
>   Filesystem                        Size  Used Avail Use% Mounted on
>   /dev/mapper/vg02-localworkspaces  250G  250G   20K 100% /workspaces/calvin
>   -r--r--r-- 1 andrkrey users 5438435328 Oct 11 17:03 .git/objects/pack/tmp_pack_xB7DMt
>   rm: remove write-protected regular file '.git/objects/pack/tmp_pack_xB7DMt'? y
>   Filesystem                        Size  Used Avail Use% Mounted on
>   /dev/mapper/vg02-localworkspaces  250G  245G  5.1G  98% /workspaces/calvin
>
> git version 2.15.0.rc0

I can imagine this behavior of retaining tmp_pack being useful for debugging in some circumstances, but I agree with you that it is certainly not a good default.

Chasing this down, I find:
  pack-write.c::create_tmp_packfile chooses the filename
  builtin/pack-objects.c::write_pack_file writes to it and the .bitmap, calling
  pack-write.c::finish_tmp_packfile to rename it into place

Nothing tries to install an atexit handler to do anything special to it on exit.

The natural thing, I'd expect, would be for pack-write to use the tempfile API (see tempfile.h) to create and finish the file. That way, we'd get such atexit handlers for free. If we want a way to keep temp files for debugging on abnormal exit, we could set that up separately as a generic feature of the tempfile API (e.g. an envvar GIT_KEEP_TEMPFILES_ON_FAILURE), making that an orthogonal topic.

Does using create_tempfile there seem like a good path forward to you? Would you be interested in working on it (either writing a patch with such a fix or a test in t/ to make sure it keeps working)?

Thanks, Jonathan

Previous: Andreas KreyNext: Andreas Krey
Message 2 of 6 in “git repack leaks disk space on ENOSPC”
  1. Andreas KreyOct 11, 2017
  2. Jonathan NiederOct 12, 2017
  3. Andreas KreyOct 12, 2017
  4. brian m. carlsonOct 12, 2017
  5. Jeff KingOct 12, 2017
  6. Jeff KingOct 12, 2017

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.