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

Re: [PATCH] {fetch,receive}-pack: drop unpack-objects, delay loosing objects until the end

From
Jeff King <peff@peff.net>
Date
Sep 3, 2013, 17:25 UTC
Message-ID
<20130903172514.GB1050@sigill.intra.peff.net>
In-Reply-To
<CACsJy8ButV8Y6Rm=F8dLTw3NvRCJZ1RgJ5f-591ASbOqfDRRTQ@mail.gmail.com>
On Tue, Sep 03, 2013 at 06:56:23PM +0700, Nguyen Thai Ngoc Duy wrote:
Show 16 quoted lines
> > ...but the cost is paid by total pack size, not number of objects. So if
> > I am pushing up a commit with a large uncompressible blob, I've
> > effectively doubled my disk I/O. It would make more sense to me for
> > index-pack to learn command-line options specifying the limits, and then
> > to operate on the pack as it streams in. E.g., to decide after seeing
> > the header to unpack rather than index, or to drop large blobs from the
> > pack (and put them in their own pack directly) as we are streaming into
> > it (we do not know the blob size ahead of time, but we can make a good
> > guess if it has a large on-disk size in the pack).
> 
> Yeah letting index-pack do the work was my backup plan :) I think if
> there is a big blob in the pack, then the pack should not be unpacked
> at all. If you store big blobs in a separate pack you already pay the
> the lookup cost of one more pack in find_pack_entry(), why go through
> the process of unpacking? index-pack still has the advantage of
> streaming though. Will rework.

In general, our large-blob strategy is to push them out to their own pack so that we do not incur the I/O overhead of rewriting them whenever we repack. But the flipside is that we have to pay the cost of an extra .idx open and lookup for each such object. In the longer term, I think it might make sense to be able to generate a multi-pack .idx for such a case (or even to simply store the large blobs in a special area indexed by the object sha1, as we do for loose objects).

But that is all orthogonal to your patch. I think as long as we are moving towards "index-pack makes the decisions while it processes the pack" we are going in a good direction. Even if we do not implement all of the decisions immediately, it leaves room for doing so later without loss of efficiency.

-Peff
Previous: Duy NguyenNext: Nguyễn Thái Ngọc Duy
Message 5 of 12 in “{fetch,receive}-pack: drop unpack-objects, delay loosing objects until the end”
  1. {fetch,receive}-pack: drop unpack-objects, delay loosing objects until the endNguyễn Thái Ngọc Duy, Sep 2, 2013
  2. Eric SunshineSep 2, 2013
  3. Jeff KingSep 3, 2013
  4. Duy NguyenSep 3, 2013
  5. Jeff KingSep 3, 2013
  6. 1/3 index-pack: add --unpack-limit to unpack objectsNguyễn Thái Ngọc Duy, Sep 6, 2013
  7. 2/3 fetch-pack: use index-pack --unpack-limit instead of unpack-objectsNguyễn Thái Ngọc Duy, Sep 6, 2013
  8. Jeff KingSep 8, 2013
  9. 3/3 receive-pack: use index-pack --unpack-limit instead of unpack-objectsNguyễn Thái Ngọc Duy, Sep 6, 2013
  10. Jeff KingSep 8, 2013
  11. Duy NguyenSep 8, 2013
  12. Jeff KingSep 8, 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.