On Thu, Mar 24, 2022 at 10:44 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Neeraj K. Singh via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > V3 changes: > > > > * Rebrand plug/unplug-bulk-checkin to "begin_odb_transaction" and > > "end_odb_transaction" > > OK. Makes me wonder (not "object", more appropriate verb than > "object" being "be curious") how well "odb-transaction" meshes with > mechanisms to ensure that the bits hit the disk platter to protect > things outside the odb that you may or may not be covering in this > series (e.g. the index file, the refs, the working tree files). > As of this series, the odb-transaction will ensure that loose-objects (and trivially packs as well, since they're currently eagerly-synced) are efficiently made durable by the time the transaction ends. Other parts of the repo (index, refs, etc) need to be updated and synced after the odb transaction ends. Patrick's original ref syncing work at [1] also contained a batch mode delimited by the existing ref transactions. I think larger transactions would be interesting to have, but I'd argue that the current patch series is a worthwhile building block for that world. It solves the real-world multiplicative pain of adding N objects to the ODB, where each one needs to be fsynced. Patrick's batch mode solves the real-world multiplicative pain of updating R refs during a big mirror push. Even talking just about the ODB, we still have O(TreeSize) fsyncs for the updated trees and a few extra fsyncs for commits. We can add odb transactions around those things too, which should be easy enough going forward. [1] https://lore.kernel.org/git/d9aa96913b1730f1d0c238d7d52e27c20bc55390.1636544377.git.ps@xxxxxx/ > > This work is based on 'seen' at . It's dependent on ns/core-fsyncmethod. > > "at ."??? > Sorry, to make GGG/Github happy, I had to rebase onto b9f5d0358d2, which was the last non-merge commit that's present in next. Then I could target next with the PR and get the right set of patches. Basing on fd008b1442 didn't work because GGG doesn't want to see a merge commit in the set of changes not in the target branch.
