Neeraj Singh <nksingh85@xxxxxxxxx> writes: > I think my new usage is congruent with the existing API, which seems > to be about combining multiple add operations into a large transaction, > where we can do some cleanup operations once we're finished. In the > preexisting code, the transaction is about adding a bunch of large objects > to a single pack file (while leaving small objects loose), and then completing > the packfile when the adds are finished. OK, so it was part me, and part a suboptimal presentation, I guess ;-) Let me rephrase the idea to see if I got it right this time. The bulk-checkin API has two interesting entry points, "plug" that signals that we are about to repeat possibly many operations to add new objects to the object store, and "unplug" that signals that we are done such adding. They are meant to serve as a hint for the object layer to optimize its operation. So far the only way the hint was used was that the logic that sends an overly large object into a packfile (instead of storing it loose, which leaves it subject to expensive repacking later) can shove more than one such objects in the same packfile. This series invents another use of the "plug"-"unplug" hint. By knowing that many loose object files are created and when the series of object creation ended, we can avoid having to fsync each and every one of them on certain filesystems and achieve the same robustness. The new "batch" option to core.fsyncmethod triggers this mechanism. Did I get it right, more-or-less? Thanks.
