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

Re: GSoC - Designing a faster index format

From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date
Mar 26, 2012, 16:19 UTC
Message-ID
<CACsJy8AqQdWO4E2oYTMLbpYhxobH8iXE-jXPoj2BcEGtfh+T=Q@mail.gmail.com>
In-Reply-To
<87iphrjv23.fsf@thomas.inf.ethz.ch>
On Mon, Mar 26, 2012 at 9:28 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Doesn't that venture into database land?

How about this (a bit like memory management). Maybe it's simpler than a database and fits us better.

The header consists of crc32 and three uint32_t, one points to the root tree, one the first extension block, the last one the free list at the end of the file. The rest of the file contains sizable blocks. There can be free space between them. Free spaces (offset and size) are recorded at the end of the file, pointed in header. The header's crc32 covers the header and free list.

When we need a new block, we look up in free list. If we cannot find a suitable space, we append to the end of the file (moving free list further to keep it always the end of the file). Removing a block means marking it in free list. We only truncate if there is free space at the end. Operations that we know will scratch the whole index are our opportunity to rewrite the index and make it compact again. No random garbage collection (iow disk is cheap).

A block starts with a signature (a tree block, or an extension...). A tree block consists of:

 - uint32_t tree object's size
 - sha-1 of tree object
 - crc32 of the rest of the block except tree object
 - maybe reference counter of a block can be refered by many blocks??
 - tree object (i.e. something that tree-walk.c can parse)
 - other index attributes, stored separately in the same order as in
tree object above, uint32_t block offset of subdirectories.

An extension block basically consists of what we have now in an extension plus uint32_t offset to the next extension block, so we can keep track of all extensions. crc32 is used for extension blocks.

This way we only need to verify checksum of the header (and free list) and blocks we visit. We don't need cache-tree extension because it's part of the format. There will be headache with unpack-trees.c because of entry order change. But in the end we would use the same order tree objects are using now, much simpler for us.

-- 
Duy
Previous: Nguyen Thai Ngoc DuyNext: elton sky
Message 21 of 33 in “GSoC - Designing a faster index format”
  1. elton skyMar 20, 2012
  2. Nguyen Thai Ngoc DuyMar 21, 2012
  3. Thomas RastMar 21, 2012
  4. elton skyMar 21, 2012
  5. elton skyMar 22, 2012
  6. Jakub NarebskiMar 23, 2012
  7. Nguyen Thai Ngoc DuyMar 23, 2012
  8. elton skyMar 23, 2012
  9. Nguyen Thai Ngoc DuyMar 23, 2012
  10. Nguyen Thai Ngoc DuyMar 24, 2012
  11. elton skyMar 26, 2012
  12. elton skyMar 26, 2012
  13. Thomas RastMar 26, 2012
  14. Nguyen Thai Ngoc DuyMar 26, 2012
  15. Shawn PearceMar 26, 2012
  16. elton skyMar 27, 2012
  17. David BarrMar 27, 2012
  18. Nguyen Thai Ngoc DuyMar 27, 2012
  19. Jeff KingMar 29, 2012
  20. Nguyen Thai Ngoc DuyMar 27, 2012
  21. Nguyen Thai Ngoc DuyMar 26, 2012
  22. elton skyMar 27, 2012
  23. Nguyen Thai Ngoc DuyMar 27, 2012
  24. elton skyApr 2, 2012
  25. Nguyen Thai Ngoc DuyApr 2, 2012
  26. Shawn PearceApr 2, 2012
  27. Nguyen Thai Ngoc DuyApr 2, 2012
  28. elton skyApr 4, 2012
  29. Nguyen Thai Ngoc DuyApr 4, 2012
  30. elton skyApr 4, 2012
  31. elton skyApr 6, 2012
  32. elton skyApr 6, 2012
  33. elton skyApr 7, 2012

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.