{I posted this to darwin-userlevel on Monday and got no response, so I’m trying again here. Apologies if you see it twice.} Back in the day (circa 2005) I got the religion about using ioctl(F_FULLFSYNC) to ensure that data written to the filesystem has actually been securely saved to disk. fsync() is not sufficient: it writes kernel buffers to the disk controller, but afterwards the controller still has several megabytes in its internal cache that haven’t been written to the platters yet, which can be lost if there’s an immediate power failure. (This isn’t the sort of thing that most apps have to worry about, since they tend to rewrite the entire file to a temp location and then swap, but it’s important for databases and other software that updates files in place. SQLite uses F_FULLFSYNC, for example.) I’m now working with a team that’s implementing a new b-tree storage manager (somewhat like Tokyo Cabinet, for instance). They’re currently calling regular fsync to commit writes. I’m telling them about F_FULLFSYNC, but a lot of time has passed since I first learned about this and I’m unsure how much of what I know is still relevant. * Do modern-day disk controllers still block completely while processing a cache flush operation? * How does the behavior of SSD controllers differ from hard disks? * Is F_FULLFSYNC important on iOS devices, since they never suffer abrupt power failures, instead shutting down cleanly when the battery level drops too low? (But judging by how long it takes to issue an END TRANSACTION statement in SQLite, that codebase still seems to be using it on iOS.) Thanks, —Jens _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app... This email sent to site_archiver@lists.apple.com