On Tue, Jan 23, 2018 at 12:45:53AM -0500, Theodore Ts'o wrote: > What I was thinking about instead is that in cases where we know we > are likely to be creating a large number of loose objects (whether > they referenced or not), in a world where we will be calling fsync(2) > after every single loose object being created, pack files start > looking *way* more efficient. So in general, if you know you will be > creating N loose objects, where N is probably around 50 or so, you'll > want to create a pack instead. > > One of those cases is "repack -A", and in that case the loose objects > are all going tobe not referenced, so it would be a "cruft pack". But > in many other cases where we might be importing from another DCVS, > which will be another case where doing an fsync(2) after every loose > object creation (and where I have sometimes seen it create them *all* > loose, and not use a pack at all), is going to get extremely slow and > painful. Ah, I see. I think in the general case of git operations this is hard (because most object writes don't realize the larger operation that they're a part of). But I agree that those two are the low-hanging fruit (imports should already be using fast-import, and "cruft packs" are not too hard an idea to implement). I agree that a cruft-pack implementation could just be for "repack -A", and does not have to collect otherwise loose objects. I think part of my confusion was that you and I are coming to the idea from different angles: you care about minimizing fsyncs, and I'm interested in stopping the problem where you have too many loose objects after running auto-gc. So I care more about collecting those loose objects for that case. > > So if we pack all the loose objects into a cruft pack, the mtime of the > > cruft pack becomes the new gauge for "recent". And if we migrate objects > > from old cruft pack to new cruft pack at each gc, then they'll keep > > getting their mtimes refreshed, and we'll never drop them. > > Well, I was assuming that gc would be a special case which doesn't the > mtime of the old cruft pack. (Or more generally, any time an object > is gets copied out of the cruft pack, either to a loose object, or to > another pack, the mtime on the source pack should not be touched.) Right, that's the "you have multiple cruft packs" idea which has been discussed[1] (each one just hangs around until its mtime expires, and may duplicate objects found elsewhere). That does end up with one pack per gc, which just punts the "too many loose objects" to "too many packs". But unless the number of gc runs you do is very high compared to the expiration time, we can probably ignore that. -Peff [1] https://public-inbox.org/git/20170610080626.sjujpmgkli4muh7h@xxxxxxxxxxxxxxxxxxxxx/
