Taylor Blau <me@xxxxxxxxxxxx> writes: > This series implements "cruft packs", a pack which stores accumulated > unreachable objects, along with a new ".mtimes" file which tracks each > object's last known modification time. Let me rephrase the above to test my understanding, since I need to write a summary for the "What's cooking" report. Instead of leaving unreachable objects in loose form when packing, or ejecting them into loose form when repacking, gather them in a packfile with an auxiliary file that records the last-use time of these objects. That way, we do not have to waste so many inodes for loose objects that is not likely to be used, which feels like a win. > - The final patch handles object freshening for objects stored in a > cruft pack. I am not going to read it today, but I think this is the most interesting part of the series. Instead of using mtime of an individual loose object file, we'd need to record the time of last use for each object in a pack. Stepping back a bit, I do not see how we can get away without doing the same .mtimes file for non-cruft packs. An object that is in a non-cruft pack may be referenced immediately after the repack that created the pack, but the ref that was referencing the object may have gone away and now the pack is a month old. If we were to repack the object, we do not know when was the last time the object was reachable from any of the refs and index entries (collectively known as anchor points). Of course, recording all mtimes for all packed objects all the time would involve quite a lot of overhead. I am guessing (I will not spend time today to figure it out myself) that .mtimes update at runtime will happen in-place (i.e. via seek(2)+write(2), or pwrite()), and I wonder what the safety concern would be (which is the primary reason why we tend not to do in-place updates but recreate-and-rename updates). Thanks for working on such an interesting topic.
