That blog post is from 2005. There was a major rework of how the block layer handles flushes back around 2010 and I'm pretty sure the issue he was having with fsync not being reliable has been resolved.

To go into the details, essentially, its the AHCI-driver(SATA) that handles 2 use-cases differently.

The more common being the case where there is an additional VFS driver between the app attempting sync-I/O and the AHCI driver which simply issues an asynchronous I/O command to the disk and returns immediately. The new data is guaranteed to be on the HDD but NOT guaranteed to be written to the non-volatile platter of the HDD. Data is often still in the HDD internal-cache, waiting to be written to the disk platter.

The 2nd case (very rare) is when the application attempting sync-I/O opens the HDD in raw mode i.e. opens the block device directly(without any VFS layer in between) with O_SYNC. Now following each disk-write, the AHCI driver issues a CMD_FLUSH to ensure that even the HDD cache is immediately flushed to the platter. As this eliminates any chance for NCQ to kick in, the performance drops by an order of magnitude but data-integrity is ensured.