I wonder if anyone is in a position to compare and contrast the
journal_mode and synchronous settings with the various ext3 journal
modes?
Up until now we've been using ext3 with data=ordered, and sqlite3 with
synchronous=normal, journal_mode=delete. We're on an embedded system
with a very high frequency of random power cycling. In this mode, we've
seen an unusually large number of corrupted databases.
My best theory right now is that we lose power after the ext3 metadata
has written the delete of the -journal file, but before all of the page
overwrites for the db file are fully flushed, since these are done by
two different processes in normal linux. I believe if we lose power at
this point, then after a restart ext3 will replay the journal delete,
but will leave the main DB in a semi-written state, and thus corrupt the
DB.
I'm wondering what impact switching to journal_mode=persist will have on
this scenario. I believe this will change how the last step of the
atomic commit (clearing the journal) is written to disk, and thus
changes how ext3 will recover the file after a power loss. Currently
our IO scheduler doesn't guarantee ordered writes, so in theory the
journal header clearing could still make it to disk before all the main
db pages. We're in a position to adjust the IO scheduler if necessary
to prevent this.
Are there any other potential holes or races between ext3 journal data
and sqlite file contents that I should worry about? Is synchronous=full
the only way to guarantee atomic commits under these conditions?
--Bob
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
