Re: fsync error reporting

[Jason Thorpe <thorpej%me.com@localhost>]

> On Feb 18, 2021, at 5:43 PM, David Holland <dholland-tech%netbsd.org@localhost> wrote:
> 
> And currently there's a problem that the only way to flush the
> underlying hardware-level caches is to call fsync_range and pass
> FDISKSYNC. This might be POSIX (is it? man page doesn't say so) but it
> doesn't necessarily seem helpful or the right way to go about handling
> this issue.

The XNU kernel provides an interface called F_FULLFSYNC.  macOS’s fsync(2) man page states:

<quote>
     For applications that require tighter guarantees about the integrity of
     their data, Mac OS X provides the F_FULLFSYNC fcntl.  The F_FULLFSYNC
     fcntl asks the drive to flush all buffered data to permanent storage.
     Applications, such as databases, that require a strict ordering of writes
     should use F_FULLFSYNC to ensure that their data is written in the order
     they expect.  Please see fcntl(2) for more detail.
</quote>

..and in fcntl(2):

<quote>
     F_FULLFSYNC        Does the same thing as fsync(2) then asks the drive to
                        flush all buffered data to the permanent storage
                        device (arg is ignored).  As this drains the entire
                        queue of the device and acts as a barrier, data that
                        had been fsync'd on the same device before is guaran-
                        teed to be persisted when this call returns.  This is
                        currently implemented on HFS, MS-DOS (FAT), Universal
                        Disk Format (UDF) and APFS file systems.  The opera-
                        tion may take quite a while to complete.  Certain
                        FireWire drives have also been known to ignore the
                        request to flush their buffered data.
</quote>

-- thorpej