O_DSYNC on Darwin is completely broken for the last 15 years
Opinion. The bizarro thing with this is that O_&lt;xzy&gt; flags are for a per file open, but the guarantees can only be supported by an underlying filesystem.<p>On Linux you can mount a filesystem and invalidate some metadata updates using options such as noatime. This is also depends on the mounted filesystem, such as FAT, which might not even support the updated attributes. Are these constraints honored in these environments with these flags? (sorry, too lazy to write code and check this)<p>There is no data on what is actually &quot;broken&quot; or why it might violate POSIX.1-2008. What metadata is actually important or impactful?<p>I am very, very skeptical of claims made by some database folks, due to past experience. Some Oracle products, and from what I understand, still do not understand that monotonically increasing means greater than or equal to (&gt;=). The equal to is the problem, because calling an absolute value timestamp function to derive a &quot;unique&quot; value will always fail (with the same return value) when you get faster hardware and more cores. In a past life (~2000), I had to add code to bork an operating system to appease this very misguided notion. Last month (May 2022) I got (2nd hand) info that after a hardware update to faster hardware, duplicate unique row_ids were being created in an Oracle DB.<p>Without additional details, I find it hard to understand what the issue actually is. Is this a detectable temporal violation of order of operations for a live system, or some sort of fail situation where an abort &#x2F; reboot occurs -- would love to understand how the external logging of this was carried out, because how was that synchronized &#x2F; timestamped?