Thread (3 messages) 3 messages, 3 authors, 2022-02-14

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

From: Junio C Hamano <hidden>
Date: 2022-02-11 23:15:26

Neeraj Singh [off-list ref] writes:
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.
Would they?   If they think platform default is performant and safe
enough for their use, as long as our adjustment is out outrageously
more dangerous or less performant, I do not think "no weaker than"
is a strict requirement.  If we were overly conservative in some
areas than the "platform default", making it less conservative in
those areas to match the looseness of other areas should be OK and
vice versa.
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?
In any case, if others who reviewed the series in the past are happy
with the "two knobs" approach and are willing to jump in to help new
users who will be confused with one knob too many, I actually am OK
with the series that I called "overly complex".  Let me let them
weigh in before I can answer that question.

Thanks.

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help