"Jim C. Nasby" <[EMAIL PROTECTED]> wrote: > On Mon, Jan 09, 2006 at 09:08:10PM -0800, Dan Kennedy wrote: > > > > The short version: > > > > The first write operation writes the parts of the database that > > are about to be overwritten to the journal file. If something > > goes wrong during the second write, the journal file will be > > used to restore the database to it's previous state. The second > > write is the one that actually modifies the database file. > > Yes, but the second write (to the data files) isn't time critical. > Because it doesn't (or at least shouldn't) be getting fsync'd very > often, it can also be re-ordered by the OS (and possibly the drive). > > In any case, it's completely inaccurate to say that each transaction > requires two revolutions of the drive. Also, if SQLite supports it, > putting the log files on a seperate set of drives from the tables is > almost always a win.
The second sync has to occur before deleting the rollback journal. Otherwise a powerloss could leave you with both an incomplete write and a missing rollback journal. The rollback journal must always be located in the same directory as the original database file so that SQLite will know where to find it. If the rollback journal is located on a separate volume, that volume might not get mounted after a power failure of system crash, and you'd then be left with a corrupted database. Besides that, how would SQLite know where to look for the rollback journal if it is off in some other directory someplace? Remember, SQLite is designed to be robust and easy to operate which means we cannot control the placement of the rollback journal using a configuration file. -- D. Richard Hipp <[EMAIL PROTECTED]>
