| Message ID | pull.1093.v3.git.1639011433.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | A design for future-proofing fsync() configuration | expand |
Hello Everyone,
I wanted to revive this thread in the new year.
To summarize the current state of affairs:
* The current fsync patch series implements two new configuration options:
core.fsync = <comma-separate list> -- select which repo
components will be fsynced
core.fsyncMethod = fsync|writeout-only -- select what form of
fsyncing will be done
* This patch series now ignores core.fsyncObjectFiles with a
deprecation warning pointing the user at core.fsync.
* There is a follow-on series that will extend the core.fsyncMethod to
also include a `batch` mode that speeds up bulk operations by avoiding
repeated disk cache flushes.
* I developed the current mechanism after Ævar pointed out that the
original `core.fsyncObjectFiles=batch` change would cause older
versions of Git to die() when exposed to a new configuration. There
were also several fsync changes floating around, including Patrick
Steinhardts `core.fsyncRefFiles` change [1] and Eric Wong's
`core.fsync = false` change [2].
* The biggest sticking points are in [3]. The fundamental
disagreement is about whether core.fsync should look like:
A) core.fsync = objects,commit-graph [current patch implementation]
or
B) core.fsync = objects
core.fsync = commit-graph [Ævar's multivalued proposal].
I prefer sticking with (A) for reasons spelled out in the thread. I'm
happy to re-litigate this discussion though.
* There's also a sticking point about whether we should fsync when
invoking pack-objects against stdout. I think that mostly reflects a
missing comment in the code rather than a real disagreement.
* Now that ew/test-wo-fsync has been integrated, there's some
redundancy between core.fsync=none and Eric's patch.
Open questions:
1) What format should we use for the core.fsync configuration to
select individual repo components to sync?
2) Are we okay with deprecating core.fsyncObjectFiles in a single
release with a warning?
3) Is it reasonable to expect people adding new persistent files to
add and document new values of the core.fsync settings?
Thanks,
Neeraj
[1] https://lore.kernel.org/git/20211030103950.M489266@dcvr/
[2] https://lore.kernel.org/git/20211028002102.19384-1-e@80x24.org/
[3] https://lore.kernel.org/git/211207.86wnkgo9fv.gmgdl@evledraar.gmail.com/
On January 7, 2022 8:14 PM, Neeraj Singh wrote: > Hello Everyone, > I wanted to revive this thread in the new year. > > To summarize the current state of affairs: > * The current fsync patch series implements two new configuration options: > core.fsync = <comma-separate list> -- select which repo components will > be fsynced > core.fsyncMethod = fsync|writeout-only -- select what form of fsyncing > will be done > > * This patch series now ignores core.fsyncObjectFiles with a deprecation > warning pointing the user at core.fsync. > > * There is a follow-on series that will extend the core.fsyncMethod to also > include a `batch` mode that speeds up bulk operations by avoiding repeated > disk cache flushes. > > * I developed the current mechanism after Ævar pointed out that the original > `core.fsyncObjectFiles=batch` change would cause older versions of Git to > die() when exposed to a new configuration. There were also several fsync > changes floating around, including Patrick Steinhardts `core.fsyncRefFiles` > change [1] and Eric Wong's `core.fsync = false` change [2]. > > * The biggest sticking points are in [3]. The fundamental disagreement is > about whether core.fsync should look like: > A) core.fsync = objects,commit-graph [current patch implementation] > or > B) core.fsync = objects > core.fsync = commit-graph [Ævar's multivalued proposal]. > I prefer sticking with (A) for reasons spelled out in the thread. I'm happy to re- > litigate this discussion though. > > * There's also a sticking point about whether we should fsync when invoking > pack-objects against stdout. I think that mostly reflects a missing comment in > the code rather than a real disagreement. > > * Now that ew/test-wo-fsync has been integrated, there's some redundancy > between core.fsync=none and Eric's patch. > > Open questions: > 1) What format should we use for the core.fsync configuration to select > individual repo components to sync? > 2) Are we okay with deprecating core.fsyncObjectFiles in a single release with > a warning? > 3) Is it reasonable to expect people adding new persistent files to add and > document new values of the core.fsync settings? > > Thanks, > Neeraj > > [1] https://lore.kernel.org/git/20211030103950.M489266@dcvr/ > [2] https://lore.kernel.org/git/20211028002102.19384-1-e@80x24.org/ > [3] > https://lore.kernel.org/git/211207.86wnkgo9fv.gmgdl@evledraar.gmail.com/ Neeraj, Please remember that fsync() is operating system and version specific. You cannot make any assumptions about what is supported and what is not. I have recently had issues with git built on a recent operating system not running on a version from 2020. The proposed patches do not work, as I recall, in a portable manner, so caution is required making this change. You can expect this not to work on some platforms and some versions. Please account for that. Requiring users who are not aware of OS details to configure git to function at all is a bad move, in my view - which has not changed since last time. Thanks, Randall
On Sat, Jan 8, 2022 at 4:55 PM <rsbecker@nexbridge.com> wrote: > > Please remember that fsync() is operating system and version specific. You cannot make any assumptions about what is supported and what is not. I have recently had issues with git built on a recent operating system not running on a version from 2020. The proposed patches do not work, as I recall, in a portable manner, so caution is required making this change. You can expect this not to work on some platforms and some versions. Please account for that. Requiring users who are not aware of OS details to configure git to function at all is a bad move, in my view - which has not changed since last time. > There was already an implied configuration of fsync in the Git codebase. None of the defaults are changing--assuming that a user does not explicitly configure the core.fsync setting, Git should work the same as it always has. I don't believe the current patch series introduces any new incompatibilities. Thanks, Neeraj
This is an implementation of an extensible configuration mechanism for fsyncing persistent components of a repo. The main goals are to separate the "what" to sync from the "how". There are now two settings: core.fsync - Control the 'what', including the index. core.fsyncMethod - Control the 'how'. Currently we support writeout-only and full fsync. Syncing of refs can be layered on top of core.fsync. And batch mode will be layered on core.fsyncMethod. core.fsyncobjectfiles is removed and will issue a deprecation warning if it's seen. I'd like to get agreement on this direction before submitting batch mode to the list. The batch mode series is available to view at https://github.com/neerajsi-msft/git/pull/1. Please see [1], [2], and [3] for discussions that led to this series. One major concern I'd voice that is adverse to this change: when a new persistent file is added to the Git repo, the person adding that file will need to update this configuration code and the documentation. Maybe this is the right thing to always think about, but the FSYNC_COMPONENT lists will be a single place that will receive a number of updates over time. Note: There's a minor conflict with ns/tmp-objdir. In object-file.c:close_loose_object we need to resolve it like this: if (!the_repository->objects->odb->will_destroy) fsync_component_or_die(FSYNC_COMPONENT_LOOSE_OBJECT, fd, "loose object file"); V3 changes: * Remove relative path from git-compat-util.h include [4]. * Updated newly added warning texts to have more context for localization [4]. * Fixed tab spacing in enum fsync_action * Moved the fsync looping out to a helper and do it consistently. [4] * Changed commit description to use camelCase for config names. [5] * Add an optional fourth patch with derived-metadata so that the user can exclude a forward-compatible set of things that should be recomputable given existing data. V2 changes: * Updated the documentation for core.fsyncmethod to be less certain. writeout-only probably does not do the right thing on Linux. * Split out the core.fsync=index change into its own commit. * Rename REPO_COMPONENT to FSYNC_COMPONENT. This is really specific to fsyncing, so the name should reflect that. * Re-add missing Makefile change for SYNC_FILE_RANGE. * Tested writeout-only mode, index syncing, and general config settings. [1] https://lore.kernel.org/git/211110.86r1bogg27.gmgdl@evledraar.gmail.com/ [2] https://lore.kernel.org/git/dd65718814011eb93ccc4428f9882e0f025224a6.1636029491.git.ps@pks.im/ [3] https://lore.kernel.org/git/pull.1076.git.git.1629856292.gitgitgadget@gmail.com/ [4] https://lore.kernel.org/git/CANQDOdf8C4-haK9=Q_J4Cid8bQALnmGDm=SvatRbaVf+tkzqLw@mail.gmail.com/ [5] https://lore.kernel.org/git/211207.861r2opplg.gmgdl@evledraar.gmail.com/ Neeraj Singh (4): core.fsyncmethod: add writeout-only mode core.fsync: introduce granular fsync control core.fsync: new option to harden the index core.fsync: add a `derived-metadata` aggregate option Documentation/config/core.txt | 35 ++++++++--- Makefile | 6 ++ builtin/fast-import.c | 2 +- builtin/index-pack.c | 4 +- builtin/pack-objects.c | 8 ++- bulk-checkin.c | 5 +- cache.h | 49 +++++++++++++++- commit-graph.c | 3 +- compat/mingw.h | 3 + compat/win32/flush.c | 28 +++++++++ config.c | 90 ++++++++++++++++++++++++++++- config.mak.uname | 3 + configure.ac | 8 +++ contrib/buildsystems/CMakeLists.txt | 3 +- csum-file.c | 5 +- csum-file.h | 3 +- environment.c | 3 +- git-compat-util.h | 24 ++++++++ midx.c | 3 +- object-file.c | 3 +- pack-bitmap-write.c | 3 +- pack-write.c | 13 +++-- read-cache.c | 19 ++++-- wrapper.c | 64 ++++++++++++++++++++ write-or-die.c | 10 ++-- 25 files changed, 354 insertions(+), 43 deletions(-) create mode 100644 compat/win32/flush.c base-commit: abe6bb3905392d5eb6b01fa6e54d7e784e0522aa Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1093%2Fneerajsi-msft%2Fns%2Fcore-fsync-v3 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1093/neerajsi-msft/ns/core-fsync-v3 Pull-Request: https://github.com/gitgitgadget/git/pull/1093 Range-diff vs v2: 1: e79522cbdd4 ! 1: 15edfe51509 core.fsyncmethod: add writeout-only mode @@ Metadata ## Commit message ## core.fsyncmethod: add writeout-only mode - This commit introduces the `core.fsyncmethod` configuration + This commit introduces the `core.fsyncMethod` configuration knob, which can currently be set to `fsync` or `writeout-only`. The new writeout-only mode attempts to tell the operating system to @@ Commit message directive to the storage controller. This change updates fsync to do fcntl(F_FULLFSYNC) to make fsync actually durable. We maintain parity with existing behavior on Apple platforms by setting the default value - of the new core.fsyncmethod option. + of the new core.fsyncMethod option. Signed-off-by: Neeraj Singh <neerajsi@microsoft.com> @@ compat/mingw.h: int mingw_getpagesize(void); ## compat/win32/flush.c (new) ## @@ -+#include "../../git-compat-util.h" ++#include "git-compat-util.h" +#include <winternl.h> +#include "lazyload.h" + @@ config.c: static int git_default_core_config(const char *var, const char *value, + else if (!strcmp(value, "writeout-only")) + fsync_method = FSYNC_METHOD_WRITEOUT_ONLY; + else -+ warning(_("unknown %s value '%s'"), var, value); ++ warning(_("ignoring unknown core.fsyncMethod value '%s'"), value); + + } + @@ git-compat-util.h: __attribute__((format (printf, 1, 2))) NORETURN +#endif + +enum fsync_action { -+ FSYNC_WRITEOUT_ONLY, -+ FSYNC_HARDWARE_FLUSH ++ FSYNC_WRITEOUT_ONLY, ++ FSYNC_HARDWARE_FLUSH +}; + +/* @@ wrapper.c: int xmkstemp_mode(char *filename_template, int mode) return fd; } ++/* ++ * Some platforms return EINTR from fsync. Since fsync is invoked in some ++ * cases by a wrapper that dies on failure, do not expose EINTR to callers. ++ */ ++static int fsync_loop(int fd) ++{ ++ int err; ++ ++ do { ++ err = fsync(fd); ++ } while (err < 0 && errno == EINTR); ++ return err; ++} ++ +int git_fsync(int fd, enum fsync_action action) +{ + switch (action) { @@ wrapper.c: int xmkstemp_mode(char *filename_template, int mode) + * on macOS, fsync just causes filesystem cache writeback but does not + * flush hardware caches. + */ -+ return fsync(fd); ++ return fsync_loop(fd); +#endif + +#ifdef HAVE_SYNC_FILE_RANGE @@ wrapper.c: int xmkstemp_mode(char *filename_template, int mode) + * case, since callers asking for a hardware flush may die if + * this function returns an error. + */ -+ for (;;) { -+ int err; +#ifdef __APPLE__ -+ err = fcntl(fd, F_FULLFSYNC); ++ return fcntl(fd, F_FULLFSYNC); +#else -+ err = fsync(fd); ++ return fsync_loop(fd); +#endif -+ if (err >= 0 || errno != EINTR) -+ return err; -+ } -+ + default: + BUG("unexpected git_fsync(%d) call", action); + } 2: ff80a94bf9a ! 2: 080be1a6f64 core.fsync: introduce granular fsync control @@ config.c: static int git_parse_maybe_bool_text(const char *value) + + if (!found) { + char *component = xstrndup(string, len); -+ warning(_("unknown %s value '%s'"), var, component); ++ warning(_("ignoring unknown core.fsync component '%s'"), component); + free(component); + } + 3: 86e39b8f8d1 = 3: 2207950beba core.fsync: new option to harden the index -: ----------- > 4: a830d177d4c core.fsync: add a `derived-metadata` aggregate option