On Sun, Mar 20 2022, Neeraj Singh via GitGitGadget wrote: > From: Neeraj Singh <neerajsi@xxxxxxxxxxxxx> > > One major source of the cost of fsync is the implied flush of the > hardware writeback cache within the disk drive. This commit introduces > a new `core.fsyncMethod=batch` option that batches up hardware flushes. > It hooks into the bulk-checkin plugging and unplugging functionality, > takes advantage of tmp-objdir, and uses the writeout-only support code. > > When the new mode is enabled, we do the following for each new object: > 1. Create the object in a tmp-objdir. > 2. Issue a pagecache writeback request and wait for it to complete. > > At the end of the entire transaction when unplugging bulk checkin: > 1. Issue an fsync against a dummy file to flush the hardware writeback > cache, which should by now have seen the tmp-objdir writes. > 2. Rename all of the tmp-objdir files to their final names. > 3. When updating the index and/or refs, we assume that Git will issue > another fsync internal to that operation. This is not the default > today, but the user now has the option of syncing the index and there > is a separate patch series to implement syncing of refs. Re my question in https://lore.kernel.org/git/220310.86r179ki38.gmgdl@xxxxxxxxxxxxxxxxxxx/ (which you *partially* replied to per my reading, i.e. not the fsync_nth() question) I still don't get why the tmp-objdir part of this is needed. For "git stash" which is one thing sped up by this let's go over what commands/FS ops we do. I changed the test like this: diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh index 3fc16944e9e..479a495c68c 100755 --- a/t/t3903-stash.sh +++ b/t/t3903-stash.sh @@ -1383,7 +1383,7 @@ BATCH_CONFIGURATION='-c core.fsync=loose-object -c core.fsyncmethod=batch' test_expect_success 'stash with core.fsyncmethod=batch' " test_create_unique_files 2 4 fsync-files && - git $BATCH_CONFIGURATION stash push -u -- ./fsync-files/ && + strace -f git $BATCH_CONFIGURATION stash push -u -- ./fsync-files/ && rm -f fsynced_files && # The files were untracked, so use the third parent, Then we get this output, with my comments, and I snipped some output: $ ./t3903-stash.sh --run=1-4,114 -vixd 2>&1|grep --color -e 89772c935031c228ed67890f9 -e .git/stash -e bulk_fsync -e .git/index [pid 14703] access(".git/objects/tmp_objdir-bulk-fsync-rR3AQI/fb/89772c935031c228ed67890f953c0a2b5c8316", F_OK) = -1 ENOENT (No such file or directory) [pid 14703] access(".git/objects/fb/89772c935031c228ed67890f953c0a2b5c8316", F_OK) = -1 ENOENT (No such file or directory) [pid 14703] link(".git/objects/tmp_objdir-bulk-fsync-rR3AQI/fb/tmp_obj_bdUlzu", ".git/objects/tmp_objdir-bulk-fsync-rR3AQI/fb/89772c935031c228ed67890f953c0a2b5c8316") = 0 Here we're creating the tmp_objdir() files. We then sync_file_range() and close() this. [pid 14703] openat(AT_FDCWD, "/home/avar/g/git/t/trash directory.t3903-stash/.git/objects/tmp_objdir-bulk-fsync-rR3AQI/bulk_fsync_HsDRl7", O_RDWR|O_CREAT|O_EXCL, 0600) = 9 [pid 14703] unlink("/home/avar/g/git/t/trash directory.t3903-stash/.git/objects/tmp_objdir-bulk-fsync-rR3AQI/bulk_fsync_HsDRl7") = 0 This is the flushing of the "cookie" in do_batch_fsync(). [pid 14703] newfstatat(AT_FDCWD, ".git/objects/tmp_objdir-bulk-fsync-rR3AQI/fb/89772c935031c228ed67890f953c0a2b5c8316", {st_mode=S_IFREG|0444, st_size=29, ...}, 0) = 0 [pid 14703] link(".git/objects/tmp_objdir-bulk-fsync-rR3AQI/fb/89772c935031c228ed67890f953c0a2b5c8316", ".git/objects/fb/89772c935031c228ed67890f953c0a2b5c8316") = 0 Here we're going through the object dir migration with unplug_bulk_checkin(). [pid 14703] unlink(".git/objects/tmp_objdir-bulk-fsync-rR3AQI/fb/89772c935031c228ed67890f953c0a2b5c8316") = 0 newfstatat(AT_FDCWD, ".git/objects/fb/89772c935031c228ed67890f953c0a2b5c8316", {st_mode=S_IFREG|0444, st_size=29, ...}, AT_SYMLINK_NOFOLLOW) = 0 [pid 14705] access(".git/objects/tmp_objdir-bulk-fsync-0F7DGy/fb/89772c935031c228ed67890f953c0a2b5c8316", F_OK) = -1 ENOENT (No such file or directory) [pid 14705] access(".git/objects/fb/89772c935031c228ed67890f953c0a2b5c8316", F_OK) = 0 [pid 14705] utimensat(AT_FDCWD, ".git/objects/fb/89772c935031c228ed67890f953c0a2b5c8316", NULL, 0) = 0 [pid 14707] openat(AT_FDCWD, ".git/objects/fb/89772c935031c228ed67890f953c0a2b5c8316", O_RDONLY|O_CLOEXEC) = 9 We then update the index itself, first a temporary index.stash : openat(AT_FDCWD, "/home/avar/g/git/t/trash directory.t3903-stash/.git/index.stash.19141.lock", O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC, 0666) = 8 openat(AT_FDCWD, ".git/index.stash.19141", O_RDONLY) = 9 newfstatat(AT_FDCWD, ".git/objects/fb/89772c935031c228ed67890f953c0a2b5c8316", {st_mode=S_IFREG|0444, st_size=29, ...}, AT_SYMLINK_NOFOLLOW) = 0 newfstatat(AT_FDCWD, "/home/avar/g/git/t/trash directory.t3903-stash/.git/index.stash.19141.lock", {st_mode=S_IFREG|0644, st_size=927, ...}, 0) = 0 rename("/home/avar/g/git/t/trash directory.t3903-stash/.git/index.stash.19141.lock", "/home/avar/g/git/t/trash directory.t3903-stash/.git/index.stash.19141") = 0 unlink(".git/index.stash.19141") = 0 Followed by the same and a later rename of the actual index: [pid 19146] rename("/home/avar/g/git/t/trash directory.t3903-stash/.git/index.lock", "/home/avar/g/git/t/trash directory.t3903-stash/.git/index") = 0 So, my question is still why the temporary object dir migration part of this is needed. We are writing N loose object files, and we write those to temporary names already. AFAIKT we could do all of this by doing the same tmp/rename/sync_file_range dance on the main object store. Then instead of the "bulk_fsync" cookie file don't close() the last file object file we write until we issue the fsync on it. But maybe this is all needed, I just can't understand from the commit message why the "bulk checkin" part is being done. I think since we've been over this a few times without any success it would really help to have some example of the smallest set of syscalls to write a file like this safely. I.e. this is doing (pseudocode): /* first the bulk path */ open("bulk/x.tmp"); write("bulk/x.tmp"); sync_file_range("bulk/x.tmp"); close("bulk/x.tmp"); rename("bulk/x.tmp", "bulk/x"); open("bulk/y.tmp"); write("bulk/y.tmp"); sync_file_range("bulk/y.tmp"); close("bulk/y.tmp"); rename("bulk/y.tmp", "bulk/y"); /* Rename to "real" */ rename("bulk/x", x"); rename("bulk/y", y"); /* sync a cookie */ fsync("cookie"); And I'm asking why it's not: /* Rename to "real" as we go */ open("x.tmp"); write("x.tmp"); sync_file_range("x.tmp"); close("x.tmp"); rename("x.tmp", "x"); last_fd = open("y.tmp"); /* don't close() the last one yet */ write("y.tmp"); sync_file_range("y.tmp"); rename("y.tmp", "y"); /* sync a cookie */ fsync(last_fd); Which I guess is two questions: A. do we need the cookie, or can we re-use the fd of the last thing we write? B. Is the bulk indirection needed? > + fsync_or_die(fd, "loose object file"); Unrelated nit: this API is producing sentence lego unfriendly to translators. Should be made to take an enum or something, so we can emit the relevant translated message in fsync_or_die(). Imagine getting: fsync error on '日本語は話せません' Which this will do, just the other way around for non-English speakers using the translation. (The solution is also not to add _() here, since translators will want to control the word order.) > diff --git a/cache.h b/cache.h > index 3160bc1e489..d1ae51388c9 100644 > --- a/cache.h > +++ b/cache.h > @@ -1040,7 +1040,8 @@ extern int use_fsync; > > enum fsync_method { > FSYNC_METHOD_FSYNC, > - FSYNC_METHOD_WRITEOUT_ONLY > + FSYNC_METHOD_WRITEOUT_ONLY, > + FSYNC_METHOD_BATCH > }; > > extern enum fsync_method fsync_method; > @@ -1767,6 +1768,11 @@ void fsync_or_die(int fd, const char *); > int fsync_component(enum fsync_component component, int fd); > void fsync_component_or_die(enum fsync_component component, int fd, const char *msg); > > +static inline int batch_fsync_enabled(enum fsync_component component) > +{ > + return (fsync_components & component) && (fsync_method == FSYNC_METHOD_BATCH); > +} > + > ssize_t read_in_full(int fd, void *buf, size_t count); > ssize_t write_in_full(int fd, const void *buf, size_t count); > ssize_t pread_in_full(int fd, void *buf, size_t count, off_t offset); > diff --git a/config.c b/config.c > index 261ee7436e0..0b28f90de8b 100644 > --- a/config.c > +++ b/config.c > @@ -1688,6 +1688,8 @@ static int git_default_core_config(const char *var, const char *value, void *cb) > fsync_method = FSYNC_METHOD_FSYNC; > else if (!strcmp(value, "writeout-only")) > fsync_method = FSYNC_METHOD_WRITEOUT_ONLY; > + else if (!strcmp(value, "batch")) > + fsync_method = FSYNC_METHOD_BATCH; > else > warning(_("ignoring unknown core.fsyncMethod value '%s'"), value); > > diff --git a/object-file.c b/object-file.c > index 5258d9ed827..bdb0a38328f 100644 > --- a/object-file.c > +++ b/object-file.c > @@ -1895,6 +1895,8 @@ static void close_loose_object(int fd) > > if (fsync_object_files > 0) > fsync_or_die(fd, "loose object file"); > + else if (batch_fsync_enabled(FSYNC_COMPONENT_LOOSE_OBJECT)) > + fsync_loose_object_bulk_checkin(fd); > else > fsync_component_or_die(FSYNC_COMPONENT_LOOSE_OBJECT, fd, > "loose object file"); This is related to the above comments about what minimum set of syscalls are needed to trigger this "bulk" behavior, but it seems to me that this whole API is avoiding just passing some new flags down to object-file.c and friends. For e.g. update-index that results in e.g. the "plug bulk" not being aware of HASH_WRITE_OBJECT, so with dry-run writes and the like we'll do the whole setup/teardown for nothing. Which is another reason I wondered why this couldn't be a flagged passed down to the object writing...
