On Wed, Mar 16, 2022 at 4:50 AM Bagas Sanjaya <bagasdotme@xxxxxxxxx> wrote: > > On 16/03/22 04.30, Neeraj Singh via GitGitGadget wrote: > > On a filesystem with a singular journal that is updated during name > > operations (e.g. create, link, rename, etc), such as NTFS, HFS+, or XFS > > we would expect the fsync to trigger a journal writeout so that this > > sequence is enough to ensure that the user's data is durable by the time > > the git command returns. > > > > But what about ext4? Will fsync-ing trigger writing journal? > That's a good question. So I did an experiment on ext4 which gives me some confidence: Here's my ext4 configuration: /dev/sdc on / type ext4 (rw,relatime,discard,errors=remount-ro,data=ordered) I added a new mode called core.fsyncMethod=batch-extra-fsync. This issues an extra open,fsync,close during migration from the tmp-objdir (which I confirmed is really happening using strace). The added cost of this extra operation is relatively small compared to core.fsyncMethod=fsync. That leads me to believe that (barring fs bugs), ext4 thinks that the data is already sufficiently durable that it doesn't need to issue an extra disk cache flush. See https://github.com/neerajsi-msft/git/commit/131466dd95165efc5c480d971c69ea1e9182657e for the test code. I don't particularly want to add this as a built-in mode at this point since it will be somewhat hard to document which mode a user should choose. Thanks, Neeraj
