How about using a hard-link to store the log file somewhere else? That should work transparently...
On 1/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > "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]> > >
