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. 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. Thanks.
