• Transactions per second performance is much lower for Chrome than Safari and Firefox. I had similar results back when writing IndexedDB VFS classes, and in that case Chrome was reportedly beingmore conservative with durability than Firefox, so this may be a result of the same policies.

I went down a rabbit hole trying to figure this out. First I wrote amicro-benchmark to time a bunch of OPFS writes and flushes to verify that was indeed where the difference was. Then I went on a long internet journey, and found that Chrome has a special flush implementation on Apple devices. Instead of callingfsync(), Chrome isusing an Apple-specific file control flag, F_FULLFSYNC:

if (!HANDLE_EINTR(fcntl(file_.get(),F_FULLFSYNC))) return true;

What does F_FULLFSYNC do? Basically itdoes whatfsync() is supposed to do, but doesn't:

Note that while fsync() will flush all data from the host to the drive (i.e. the "permanent storage device"), the drive itself may not physically write the data to the platters for quite some time and it may be written in an out-of-order sequence.

Specifically, if the drive loses power or the OS crashes, the application may find that only some or none of their data was written. The disk drive may also re-order the data so that later writes may be present, while earlier writes are not.

This is not a theoretical edge case. This scenario is easily reproduced with real world workloads and drive power failures.

For applications that require tighter guarantees about the integrity of their data, Mac OS X provides the F_FULLFSYNC fcntl.

I haven't been able to confirm how Firefox and Safari do syncing, but I strongly suspect that they aren't using F_FULLFSYNC. That would obviously be a serious bug, right? Maybe not.

At one time, the lack of using F_FULLFSYNC on Mac was actually filed as aFirefox bug, but it was eventually marked WONTFIX. One of the commenters on the bug is Dr. Richard Hipp, the author of SQLite:

We added the fullsync option at Apple's request. But it turns out that they don't use it themselves. The fullsync requires the OS to reset the disk controller, so it causes a significant performance impact, not only to the application using SQLite, but all other processes running on the machine that happen to be using the disk drive.

It is true that the fsync() system call does not work as advertised on MacOS (nor Linux) but in practice this does not normally cause too much trouble. The data is stored in the disk drives track buffers and it normally makes it to oxide without too much delay. My understanding is that problems caused by fsync() not working are probably no more common that problems caused by head crashes or other hard disk failures.

I would recommend that you not enable fullsync. Or if you do, at least make it a configuration option so that users can turn it off if they want.

So even Apple doesn't use F_FULLFSYNC and the SQLite folks don't recommend it (at least not back in 2008); it can be enabled in SQLite (on a native Apple build) with apragma, but the default is off. ThisSQLite forum message reports that interrupting SQLite connections not using F_FULLFSYNC could affect durability but did not find any database corruption with the specific devices and software versions tested.

It appears that all the browsers are making an informed decision about the risks and rewards here and have arrived at different conclusions, and that's the reason why Chrome is dramatically slower on OPFS flush (and therefore on OPFS VFS write transactions) on macOS and iOS. Application developers considering an OPFS VFS should be aware that:

• Chromium browsers will be slower than other browsers on Apple devices - how much slower will depend on the workload, but more than 10x in the worst case.
• On other browsers on Apple devices the expected durability is lower and the chance of database corruption is potentially higher (though very low in absolute terms).

First of all: I really appreciate your fantastic work on all of this!

Looks like you've recently shipped v1.0 (congrats!) and as part of the preparations deleted the above-mentioned ahp demos as part of#174. Are there any plans to bring those back?@rhashimoto