Subject: RE: [PATCH v2 0/6] Implement a batched fsync option for core.fsyncObjectFiles

From: "Randall S. Becker" <[email-masked]>
Date: Wed, 8 Sep 2021 09:57:34 -0400

On September 8, 2021 2:50 AM, Christoph Hellwig wrote:
>To: Junio C Hamano <[email-masked]>
>Cc: Neeraj Singh <[email-masked]>; Neeraj K. Singh via GitGitGadget <[email-masked]>; Git List <[email-masked]>;
>Johannes Schindelin <[email-masked]>; Jeff King <[email-masked]>; Jeff Hostetler <[email-masked]>; Christoph
>Hellwig <[email-masked]>; Ævar Arnfjörð Bjarmason <[email-masked]>; Neeraj K. Singh <[email-masked]>
>Subject: Re: [PATCH v2 0/6] Implement a batched fsync option for core.fsyncObjectFiles
>
>On Tue, Sep 07, 2021 at 11:44:52PM -0700, Junio C Hamano wrote:
>> I doubt that fsyncObjectFiles is something we can reliably test in CI,
>> either with the new batched thing or with the original "when we close
>> one, make sure the changes hit the disk platter" approach.  So I am
>> not sure what conclusion we should draw from such an experiment, other
>> than "ok, it compiles cleanly."  After all, unless we cause system
>> crashes, what we thought we have written and close(2) would be seen by
>> another process that we spawn after that, with or without sync, no?
>
>Basically yes.  XFS on Linux has shutdown ioctls that allow to simulate that crash by shutting the file system down which really
helps
>debugging that kind of code.  A bunch of other file systems (ext4, f2fs) have also picked this up now (grep for
>{XFS,EXT4,F2FS}_IOC_SHUTDOWN).

I strongly doubt this concept will work in an MPP architecture, particularly one where "shutting the file system down" is not
possible. I know of at least 3 operating systems where that is a bad plan, and if you did, you would take the test suite down while
you were at it.
-Randall