Hello hackers,
While following along with the nearby investigation into weird
cross-version Apple toolchain issues that confuse configure, I noticed
that the newer buildfarm Macs say:
checking for fdatasync... (cached) yes
That's a bit strange because there's no man page and no declaration:
checking whether fdatasync is declared... (cached) no
That's no obstacle for us, because c.h does:
#if defined(HAVE_FDATASYNC) && !HAVE_DECL_FDATASYNC
extern int fdatasync(int fildes);
#endif
So... does this unreleased function flush drive caches? We know that
fsync(2) doesn't, based on Apple's advice[1] for databases hackers to
call fcntl(fd, F_FULLSYNC, 0) instead. We do that.
Speaking as an armchair Internet Unix detective, my guess is: no. In
the source[2] we can see that there is a real system call table entry
and VFS support, so there is *something* wired up to this lever. On
the other hand, it shares code with fsync(2), and I suppose that
fdatasync(2) isn't going to do *more* than fsync(2). But who knows?
Not only is it unreleased, but below VNOP_FSYNC() you reach closed
source file system code.
That was fun, but now I'm asking myself: do we really want to use an
IO synchronisation facility that's not declared by the vendor? I see
that our declaration goes back 20 years to 33cc5d8a, which introduced
fdatasync(2). The discussion from the time[3] makes it clear that the
OS support was very patchy and thin back then.
Just by the way, another fun thing I learned about libSystem while
reading up on Big Sur changes is that the system libraries are no
longer on the file system. dlopen() is magical.
[1] https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/fsync.2.html
[2] https://github.com/apple/darwin-xnu/blob/d4061fb0260b3ed486147341b72468f836ed6c8f/bsd/vfs/vfs_syscalls.c#L7708
[3] https://www.postgresql.org/message-id/flat/200102171805.NAA24180%40candle.pha.pa.us
