On Fri, Feb 11, 2022 at 2:19 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Neeraj Singh <nksingh85@xxxxxxxxx> writes: > > > The main motivation for this more granular scheme is that I didn't > > think the current configuration follows a sensible principle. We > > should be fsyncing the loose objects, index, refs, and config > > files in addition to what we're already syncing today. On macOS, > > we should be doing a full hardware flush if we've said we want to > > fsync. > > If the "robustness vs performance" trade-off is unevenly made in the > current code, then that is a very good problem to address first, and > such a change is very much justified on its own. > > Perhaps "this is not a primary work repository but is used only to > follow external site to build, hence no fsync is fine" folks, who do > not have core.fsyncObjectFiles set to true, may appreciate if we > stopped doing fsync for packs and other things. As the Boolean > core.fsyncObjectFiles is the only end-user visible knob to express > how the end-users express the trade-off, a good first step would be > to align other file accesses to the preference expressed by it, i.e. > others who say they want fsync in the current scheme would > appreciate if we start fsync in places like ref-files backend. > In practice, almost all users have core.fsyncObjectFiles set to the platform default, which is 'false' everywhere besides Windows. So at minimum, we have to take default to mean that we maintain behavior no weaker than the current version of Git, otherwise users will start losing their data. The advantage of introducing a new knob is that we don't have to try to divine why the user set a particular value of core.fsyncObjectFiles. > Making the choice more granular, from Boolean "yes/no", to linear > levels, would also be a good idea. Doing both at the same time may > make it harder to explain and justify, but as long as at the end, if > "very performant" choice uniformly does not do any fsync while > "ultra durable" choice makes a uniform effort across subsystems to > make sure bits hit the platter, it would be a very good idea to do > them. > One path to get to your suggestion from the current patch series would be to remove the component-specific options and only provide aggregate options. Alternatively, we could just not document the component-specific options and leave them available to be people who read source code. So if I rename the aggregate options in terms of 'levels of durability', and only document those, would that be acceptable? Thanks for the review! -Neeraj
