Hi Neeraj, On Wed, 9 Mar 2022, Neeraj Singh wrote: > On Wed, Mar 9, 2022 at 4:21 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > I am wondering if fsync_or_die() interface is abstracted well enough, > > or we need things like "the fd is inside this directory; in addition > > to doing the fsync of the fd, please sync the parent directory as > > well" support before we start adding more components (if there is such > > a need, perhaps it comes before this step). > > > > I think syncing the parent directory is a separate fsyncMethod that > would require changes across the codebase to obtain an appropriate > directory fd. I'd prefer to treat that as a separable concern. That makes sense to me because I expect further abstraction to be necessary here because Unix/Linux semantics differ quite a bit more from Windows semantics when it comes to directory "file" descriptors than when talking about files' file descriptors. > > > +#define FSYNC_COMPONENTS_DEFAULT (FSYNC_COMPONENT_PACK | \ > > > + FSYNC_COMPONENT_PACK_METADATA | \ > > > + FSYNC_COMPONENT_COMMIT_GRAPH) > > > > IOW, everything other than loose object, which already has a > > separate core.fsyncObjectFiles knob to loosen. Everything else we > > currently sync unconditionally and the default keeps that > > arrangement? > > > > Yes, trying to keep default behavior identical on non-Windows > platforms. Windows will be expected to adopt batch mode, and have > loose objects in this set. We already adopted an early version of this patch series: https://github.com/git-for-windows/git/commit/98209a5f6e4 And yes, I will gladly adapt that to whatever lands in core Git. Thank you _so_ much for working on this! Dscho
