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

Re: Slow git pack-refs --all

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Dec 25, 2025, 23:38 UTC
Message-ID
<aU3K9lGbHw68Vv5U@fruit.crustytoothpaste.net>
In-Reply-To
<CH3PR12MB9026B5872FD42F031970074BC2B3A@CH3PR12MB9026.namprd12.prod.outlook.com>
On 2025-12-25 at 22:13:54, Martin Fick wrote:
Show 11 quoted lines
> Although the packed-refs file is large, copying it takes less than 1s,
> so there isn't a writing throughput issue with the filesystem.
> Additionally, jgit can pack-refs --all in under 20s on the same repo,
> so I don't believe there is an issue locking the 200 loose refs
> either. When observing the filesystem, I do see the packed-refs.new
> growing at a rate that seems slower than expected as if much more is
> happening while writing this file, than just writing the file.
> 
> An strace shows about 200+ open("./objects..") calls interspersed
> between around ~26K write() calls. I am surprised to see pack-refs
> reading objects at all.
I think this is from `should_pack_ref`:
    /* Do not pack broken refs: */
    if (!ref_resolves_to_object(ref->name, refs->base.repo, ref->oid, ref->flags))
    	return 0;

So Git is going to need to verify that the object at least exists. I don't know why we would need to _open_ them, however. Perhaps someone else has ideas.

Show 5 quoted lines
> Although the repository is not in terrible shape before packing refs
> (~1500 loose objects, 37pack files). Surprisingly, repacking the repo
> first does speed it up so that packing refs then takes under 20s.
> 
> This repository is on NFS.

That's almost certainly part of your performance problem, too. Loading a single pack file and index is going to be way, way faster than making lots of network calls to open 37 pack file and 37 index files, plus at least stat some loose objects.

I will note that at least some forges always have Git write pack files and try to avoid loose objects altogether since that almost always improves performance. You may want to set `receive.unpackLimit` to 1 to see if that helps in the general case.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
Previous: Martin FickNext: Jeff King
Message 2 of 19 in “Slow git pack-refs --all”
  1. Martin FickDec 25, 2025
  2. brian m. carlsonDec 25, 2025
  3. Jeff KingDec 26, 2025
  4. brian m. carlsonDec 26, 2025
  5. Jeff KingDec 27, 2025
  6. Martin FickDec 31, 2025
  7. Jeff KingJan 2, 2026
  8. Martin FickJan 5, 2026
  9. Patrick SteinhardtJan 6, 2026
  10. Martin FickJan 6, 2026
  11. Patrick SteinhardtJan 7, 2026
  12. Martin FickJan 7, 2026
  13. Patrick SteinhardtJan 8, 2026
  14. Jeff KingJan 15, 2026
  15. Martin FickJan 16, 2026
  16. Martin FickJan 7, 2026
  17. Jeff KingJan 6, 2026
  18. Martin FickJan 6, 2026
  19. Martin FickDec 31, 2025

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.