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

Slow git pack-refs --all

From
Martin Fick <mfick@nvidia.com>
Date
Dec 25, 2025, 22:13 UTC
Message-ID
<CH3PR12MB9026B5872FD42F031970074BC2B3A@CH3PR12MB9026.namprd12.prod.outlook.com>
I was hoping to get some help debugging a busy large repository where git pack-refs --all tends to regularly take over 5mins to run in production. As you can imagine this is particularly problematic on a busy Gerrit server since it tends to hold the packed-refs.lock file for most of this duration. Any help is greatly appreciated, see the details below.
-Martin
What did you do before the bug happened? (Steps to reproduce your issue)
I have a large repository (~90M objects, ~50GB, ~3M refs) which is regularly (every ~2hours) repacked and maintained, but generally gets at least 300+ updates per maintenance cycle.
What did you expect to happen? (Expected behavior)
git pack-refs --all to complete in under 20s when there are only 200 loose refs
What happened instead? (Actual behavior)
git pack-refs --all takes more than 3 minutes
What's different between what you expected and what actually happened?
This is much slower than expected
Anything else you want to add:
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.
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.

[System Info] git version: git version 2.45.2 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 compiler info: gnuc: 14.1 libc info: glibc: 2.17 $SHELL (typically, interactive shell): /bin/bash

[Enabled Hooks] not run from a git repository - no hooks to show

Next: brian m. carlson
Message 1 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.