TL;DR: If you want ACID at the OS and storage firmware level, expect to buy expensive server-rated hardware and expect it to be slow.
On 28 Jan 2013, at 12:30pm, Phil Schwan <ph...@dugeo.com> wrote: > Arguably more importantly, there's an OS page cache that sits between your > application (sqlite) and the file system. Unless you disable the cache -- > the equivalent of doing an fdatasync() after every operation anyway -- or > you have an exceptionally clever file system, the OS will combine separate > writes to the same page before they hit the disk. On 28 Jan 2013, at 12:29pm, Richard Hipp <d...@sqlite.org> wrote: > Furthermore, I'm pretty sure every modern unix-like system will usually > reorder the sequence of write()s so that data reaches oxide in a different > order from how data was written by the application. Worse still, your hard disk subsystem (You noticed your hard disk has a green circuit board on, didn't you ?) probably reorders writes too. Because this results in overall faster operation. And since it's happening at the storage module level, the OS doesn't know about it and can't stop it. You can buy expensive server-rated hard disks which have jumper settings which turn this off. They're slow. You wouldn't want to boot from one. But I have tested more than one cheap hard disk which does have the jumper settings (according to the documentation) but as far as I could see ignored them. At least sending it a lot of intentionally badly-ordered set of writes took no longer (statistical average) when I moved the jumpers. Amusingly, SSD seem to have less optimization of this kind done in storage firmware. Presumably because they're actually faster when you distribute writes between the different banks of storage. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
