On 21 May 2013, at 5:04pm, Thanumalayan Sankaranarayana Pillai <madth...@cs.wisc.edu> wrote:
> Did anyone look into this? I might be setting some config option wrong, > so it would be great if you sent me a "you did something wrong" reply if > you feel that I might have the wrong config (or might be doing something > totally idiotic). > > I tested with a few other Linux machines and a few different SQLite > versions, and found that there is an upto-5-second delay (the default > filesystem commit interval) in the transactions getting durable (with power > crashes, that is). I think it's a reflection of what the operating system thinks 'synchronous' should mean. Flushing changes to disk takes time and slows down your application so the operating system doesn't always do it when it says it does. With Unix, for example, it's quite common to find that some file systems do absolutely nothing for flush API calls, or put a timer on flush() which prevents it from running more frequently than every few seconds, which would introduce extra lag and thrashing your mass storage subsystem (e.g. wearing out the stepper motor on a hard disk). Also, hard disk subsystems (the metal thing with a circuit board you hold in your hand) aimed at desktop computers actively lie to the OS about when data is written to disk unless you buy hard disks explicitly sold for use in servers (and priced to match). Tracking down exactly what's going on would probably involve reading the source code for ftruncate() in your version of your OS, and then assuming that the hard disk unit doesn't lie. It could be done if you want, but ftruncate() differs even for different versions of the same Unix file system, so the result may not tell us much. > One more random > thought: if I'm not wrong, "SQLite crash-tests" currently tests > partial-flushing only with write() calls.... Immediate and true flushing is not a huge concern of the developer team. A delay of 5 seconds, in conditions relating to a normal running of an application, probably isn't going to be a deal-breaker in anything you should be using a DBMS for. The main thing, and one you seem to confirm is working properly, is that transactions are always either completely written or not written, never with some parts written and others not written. That's part of the ACID conditions SQLite does its best to implement, and any breaking of those conditions would get full and eager attention from the developers. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
