On 3 Mar 2014, at 3:41am, romtek <rom...@gmail.com> wrote: > Thanks, Simon. Interestingly, for this server, disk operations aren't > particularly fast. One SQLite write op takes about 4 times longer than on a > HostGator server.
That supports the idea that storage is simulated (or 'virtualised') to a high degree. > I wonder if what I/you described also means that this file system isn't > likely to support file locks needed for SQLite to control access to the DB > file to prevent data corruption. I think that's likely. Virtualisation is a pig for ACID: it introduces yet another gap between processing and physical changes in your storage which will be read after restart. For those playing along at home, doing transactions properly depends on synchronisation. Something that comes up here repeatedly is that synchronising takes a long time, and since people buy kit that quotes faster figures things at all levels lie about doing synchronisation. This leads to articles like the following: <http://www.mysqlperformanceblog.com/2006/05/03/group-commit-and-real-fsync/> "Certain OS/Hardware configurations still fake fsync delivering great performance at the cost of being non ACID" Here's a SQLite engineer writing about the same thing: section 3.1 of <https://www.sqlite.org/howtocorrupt.html> Your disk hardware, its firmware driver, the OS's storage driver, the OS's file system and the OS file API all get a chance to pretend they're doing 'sync()' but actually just return 'done it'. And if even one of them lies, synchronisation appears to happen instantly and your software runs faster. A virtualising system is another chance to do processing faster by lying about synchronisation. And unless something crashes or you have a power failure nobody will ever find out. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
