On September 8, 2021 2:50 AM, Christoph Hellwig wrote:
>To: Junio C Hamano <gitster@xxxxxxxxx>
>Cc: Neeraj Singh <nksingh85@xxxxxxxxx>; Neeraj K. Singh via GitGitGadget <gitgitgadget@xxxxxxxxx>; Git List <git@xxxxxxxxxxxxxxx>;
>Johannes Schindelin <Johannes.Schindelin@xxxxxx>; Jeff King <peff@xxxxxxxx>; Jeff Hostetler <jeffhost@xxxxxxxxxxxxx>; Christoph
>Hellwig <hch@xxxxxx>; Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>; Neeraj K. Singh <neerajsi@xxxxxxxxxxxxx>
>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
