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

From: Randall S. Becker <rsbecker@nexbridge.com>
Date: Sep 8, 2021, 13:57 UTC
Message-ID: <006d01d7a4b9$7cea64c0$76bf2e40$@nexbridge.com>
In-Reply-To: <20210908064958.GA29073@lst.de>

On September 8, 2021 2:50 AM, Christoph Hellwig wrote:

Show 16 quoted lines

>To: Junio C Hamano <gitster@pobox.com>
>Cc: Neeraj Singh <nksingh85@gmail.com>; Neeraj K. Singh via GitGitGadget <gitgitgadget@gmail.com>; Git List <git@vger.kernel.org>;
>Johannes Schindelin <Johannes.Schindelin@gmx.de>; Jeff King <peff@peff.net>; Jeff Hostetler <jeffhost@microsoft.com>; Christoph
>Hellwig <hch@lst.de>; Ævar Arnfjörð Bjarmason <avarab@gmail.com>; Neeraj K. Singh <neerajsi@microsoft.com>
>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