> On Nov 15, 2016, at 10:57 AM, Simon Slavin <slav...@bigfraud.org> wrote: > > My understanding is that F_FULLFSYNC still works the way you describe on a > Mac and SQLite still uses it the way the documentation says. But I'm not in > touch with either development group.
This seems like a strange decision, considering that in other respects SQLite (wisely) defaults to settings that favor safety and durability over performance, e.g. synchronous mode. So perhaps the “How To Corrupt A SQLite Database” page should be updated to add “Use SQLite on a Mac without knowing the secret that you should enable `pragma fullfsync`?” :-( Incidentally, that page (https://www.sqlite.org/howtocorrupt.html <https://www.sqlite.org/howtocorrupt.html>) says: >> Actually, if one is only concerned with atomic and consistent writes and is >> willing to forego durable writes, the sync operation does not need to wait >> until the content is completely stored on persistent media. Instead, the >> sync operation can be thought of as an I/O barrier. As long as all writes >> that occur before the sync are completed before any write that happens after >> the sync, no database corruption will occur. So … based on my understanding (what I was told by a filesystem guru, albeit 10 years ago), a typical fsync does _not_ act as an I/O barrier. This is because it’s not really syncing (as the same page says, "most consumer-grade mass storage devices lie about syncing”). Disk controllers don’t write physical sectors in the order in which the writes are received; instead they buffer them, and then optimize the order of writes to minimize seeks. So if power is abruptly lost, it is not true that there’s a barrier before which all writes have been persisted and after which none have; instead the pattern is likely to be random. The only way to guarantee a true barrier is to really-and-truly flush the disk controller, which requires not simply flushing but resetting it. That’s what F_FULLFSYNC on macOS does. (Unfortunately it makes the disk controller unresponsive for a macroscopic amount of time while it resets, which is why it’s slow. Worse, it adds latency to _all_ I/O on the system. Flush too often on a desktop computer and your music player will glitch, video playback will drop frames, etc.) I’m totally willing to believe that these behaviors are different with SSDs, especially ones that use newer types of interfaces or are soldered directly to the motherboard (as on some MacBooks.) I’d love to be educated about the current state of the art :) —Jens _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
