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

[<rsbecker@nexbridge.com>]

On March 10, 2022 1:43 PM, Neeraj Singh wrote:
>On Thu, Mar 10, 2022 at 10:08 AM <rsbecker@nexbridge.com> wrote:
>> While this might not be a surprise, on some platforms fsync is a thread-blocking
>operation. When the OS has kernel threads, fsync can potentially cause multiple
>processes (if implemented that way) to block, particularly where an fd is shared
>across threads (and thus processes), which may end up causing a deadlock. We
>might need to keep an eye out for this type of situation in the future and at least
>try to test for it. I cannot actually see a situation where this would occur in git, but
>that does not mean it is impossible. Food for thought.
>> --Randall
>
>fsync is expected to block the calling thread until the underlying data is durable.
>Unless the OS somehow depends on the git process to make progress before
>fsync can complete, there should be no deadlock, since there would be no cycle in
>the waiting graph.  This could be a problem for FUSE implementations that are
>backed by Git, but they already have to deal with that possiblity today and this
>patch series doesn't change anything.

That assumption is based on a specific threading model. In cooperative user-thread models, fsync is process-blocking. While fsync, by spec is required to block the thread, there are no limitations on blocking everything else. In some systems, an fsync can block the entire file system. Just pointing that out.