On Fri, Nov 10, 2023 at 08:24:44PM -0500, Taylor Blau wrote: > > This does mean that for a recursive merge, that you'll get up to 2*N > > packfiles, where N is the depth of the recursive merge. > > We definitely want to avoid that ;-). I think there are a couple of > potential directions forward here, but the most promising one I think is > due to Johannes who suggests that we write loose objects into a > temporary directory with a replace_tmp_objdir() call, and then repack > that side directory before migrating a single pack back into the main > object store. I posted an alternative in response to Elijah; the general idea being to allow the usual object-lookup code to access the in-progress pack. That would keep us limited to a single pack. It _might_ be a terrible idea. E.g., if you write a non-bulk object that references a bulk one, then that non-bulk one is broken from the perspective of other processes (until the bulk checkin is flushed). But I think we'd always be writing to one or the other here, never interleaving? -Peff
