Re: [PATCH v4 2/4] core.fsync: introduce granular fsync control

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 2, 2022, 00:51 UTC
Message-ID: <xmqqr18m8514.fsf@gitster.g>
In-Reply-To: <7a164ba95710b4231d07982fd27ec51022929b81.1643686425.git.gitgitgadget@gmail.com>

"Neeraj Singh via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 18 quoted lines

> +core.fsync::
> +	A comma-separated list of parts of the repository which should be
> +	hardened via the core.fsyncMethod when created or modified. You can
> +	disable hardening of any component by prefixing it with a '-'. Later
> +	items take precedence over earlier ones in the list. For example,
> +	`core.fsync=all,-pack-metadata` means "harden everything except pack
> +	metadata." Items that are not hardened may be lost in the event of an
> +	unclean system shutdown.
> ++
> +* `none` disables fsync completely. This must be specified alone.
> +* `loose-object` hardens objects added to the repo in loose-object form.
> +* `pack` hardens objects added to the repo in packfile form.
> +* `pack-metadata` hardens packfile bitmaps and indexes.
> +* `commit-graph` hardens the commit graph file.
> +* `objects` is an aggregate option that includes `loose-objects`, `pack`,
> +  `pack-metadata`, and `commit-graph`.
> +* `default` is an aggregate option that is equivalent to `objects,-loose-object`
> +* `all` is an aggregate option that syncs all individual components above.

I am not quite sure if this is way too complex (e.g. what does it mean that we do not care much about loose-object safety while we do care about commit-graph files?) and at the same time it is too limited (e.g. if it makes sense to say a class of items deserve more protection than another class of items, don't we want to be able to say "class X is ultra-precious so use method A on them, while class Y is mildly precious and use method B on them, everything else are not that important and doing the default thing is just fine").

If we wanted to allow the "matrix" kind of flexibility, I think the way to do so would be

	fsync.<class>.method = <value>

e.g.

	[fsync "default"] method = none
	[fsync "loose-object"] method = fsync
	[fsync "pack-metadata"] method = writeout-only

Where do we expect users to take the core.fsync settings from? Per repository? If it is from per user (i.e. $HOME/.gitconfig), do people tend to share it across systems (not necessarily over NFS) with the same contents? If so, I am not sure if fsync.method that is way too close to the actual "implementation" is a good idea to begin with. From end-user's point of view, it may be easier to express "class X is ultra-precious, and class Y and Z are mildly so", with something like fsync.<class>.level = <how-precious> and let the Git implementation on each platform choose the appropriate fsync method to protect the stuff at that precious-ness.

Thanks.