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

Re: [PATCH] git exproll: steps to tackle gc aggression

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 8, 2013, 07:13 UTC
Message-ID
<7va9ksbqpl.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CALkWK0kmx8bi1ZT1CSk+iVnmmQJV4bNu1D7h1AHnRk7_TfhJ3Q@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
Show 8 quoted lines
> Junio C Hamano wrote:
>> Imagine we have a cheap way to enumerate the young objects without
>> the usual history traversal.
>
> Before we discuss the advantages, can you outline how we can possibly
> get this data without actually walking downwards from the roots
> (refs)? One way to do it is to pull data out of a log of ref updates
> (aka. reflog), but we both know how unreliable that can be.

My understanding of the topic is to come up with a way that is much cheaper than the current "gc --auto" that involves recent history walk to consolidate both loose objects and small young packs into one, so that we can use that logic for "gc --auto".

The key phrase is "without the usual history traversal". We are talking about young objects, and they are likely to be reachable from something (like reflog entries, if not refs). We may include unreachable cruft in the result in the "let's be quick and collect them into a single young pack", and you will need to keep them while reflog entries are alive, and you will need periodic sweeps with the usual history walking to remove older crufts that recently have become unreachable due to reflog expiry from packs anyway, so it is not a problem for the pack that consolidates young objects into a single pack to contain some unreachable crufts.

If you start from that assumption [*1*], the way to enumerate the young objects without the usual history traversal should be fairly obvious.

By definition, loose objects are all young because they were created since the last "gc --auto". Also pack .idx files know their own creation timestamp to let you decide how old they are, you can see how many objects there are in the corresponding .pack and how big it is.

By doing an equivalent of "find .git/objects/[0-9a-f][0-9a-f]/", you can enumerate the loose objects, and an equivalent of "show-ref" will enumerate the objects in the pack that the .idx file you determined to be small and young.

Note that *1* is an assumption. I do not know offhand if such a "consolidate young objects quickly into one to keep the number of packs small" strategy is an overall win.

Previous: Ramkumar RamachandraNext: Ramkumar Ramachandra
Message 5 of 33 in “git exproll: steps to tackle gc aggression”
  1. git exproll: steps to tackle gc aggressionRamkumar Ramachandra, Aug 6, 2013
  2. Duy NguyenAug 6, 2013
  3. Junio C HamanoAug 6, 2013
  4. Ramkumar RamachandraAug 7, 2013
  5. Junio C HamanoAug 8, 2013
  6. Ramkumar RamachandraAug 8, 2013
  7. Junio C HamanoAug 8, 2013
  8. Martin FickAug 8, 2013
  9. Junio C HamanoAug 8, 2013
  10. Ramkumar RamachandraAug 8, 2013
  11. Ramkumar RamachandraAug 8, 2013
  12. Junio C HamanoAug 8, 2013
  13. Ramkumar RamachandraAug 8, 2013
  14. Martin LanghoffAug 8, 2013
  15. Jeff KingAug 9, 2013
  16. Ramkumar RamachandraAug 9, 2013
  17. Junio C HamanoAug 9, 2013
  18. Jeff KingAug 9, 2013
  19. Duy NguyenAug 10, 2013
  20. Jeff KingAug 10, 2013
  21. Junio C HamanoAug 10, 2013
  22. Ramkumar RamachandraAug 10, 2013
  23. Duy NguyenAug 10, 2013
  24. Duy NguyenAug 10, 2013
  25. Jeff KingAug 10, 2013
  26. Duy NguyenAug 10, 2013
  27. Ramkumar RamachandraAug 10, 2013
  28. Duy NguyenAug 10, 2013
  29. Jeff KingAug 10, 2013
  30. Martin FickAug 7, 2013
  31. Duy NguyenAug 8, 2013
  32. Martin FickAug 7, 2013
  33. Ramkumar RamachandraAug 7, 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.