[kwlug-disc] Flush to persist on Apple's NVMe drives

[Mikalai Birukou]

> One clarification missing from that thread is that MacOS fsync() has worked this way since 2004, and all of the databases with MacOS ports already know to use F_FULLSYNC instead of fsync().
>
> So the new information is just how incredibly slow F_FULLSYNC is on the M1. It's as if some intern implemented F_FULLSYNC using simple brute force, and no engineering resources were allocated to testing how fast it is, since apparently Apple doesn't use this operation in their own code.
>
> A related issue, there's an unanswered question about whether Apple's file system maintains file system integrity if there is an unexpected power loss. This isn't an issue on laptops due to the battery. But it may affect the mac mini, imac and mac pro.

This logical about laptops. Till bugs happen :) .

This argument is about laptops in general. I have Lenovo ThinkPad. 
Original battery has already died long ago. Replacement is funky. 
Battery charges, then it **may** flip to battery is empty. With power 
plugged in it **may** turn to battery power (why?). And in that moment, 
with power plugged in, it turns off, **sometimes**. I know, sounds 
crazy. I am screaming into the void every time the worst scenario happens.

Nonetheless, cute assumption about laptop having battery, isn't bullet 
proof.

>   Somebody claimed that the API for file system write barriers (ensuring that blocks are written out in the correct order) is just as slow as F_FULLSYNC. So it's not clear to me if Apple is using write barriers for file system integrity.
>> Performance versus need to persist data in observations of Apple's NVMe
>> drives: https://twitter.com/marcan42/status/1494213855387734019