Dr Hipp, Thanks for your reply.
I have contacted the authors of our filesystem HCC Embedded. The filesystem we are using is called EFFS, some information can be found at http://www.hcc-embedded.com/site.php if necessary. Apparently, yes the flash filesystem implements fully atomic writes, indeed this was one of the features that made us choose this particular filesystem. I know from development of our product that files are only updated when the file is flushed, i.e. when sqlite3OsSync() is called. Any fwrites without a flush are lost on power loss, therefore no corruption occurs. Here is a reply from the author of EFFS:- " Hi Mark - changes to the file are uilt in mirror chains - when the file is closed or flushed then the new file replaces the old - i.e. the file is updated atomically. So I think you do not need this roll back. We take the view that thisis how a failsafe file system should work - it is only meaningful to change at known states - it should not be necessary for the user to know that each write creates an update - a relibale application would be well nigh imposible to design in this environment. So we think it should work really nicely with your database and that you can disable this rollback. Would be glad if you could mention to your SQLite contact the beauty of our system (:-)) Regards Dave " I think based on your information and that from HCC that we can lose the journalling of the database without any potential data loss. Again my question is how can this be done? And how difficult would this be? I think this would benefit us a great deal as our target hardware is not the quickest and any performance enhancements would help a great deal. I would like to state that I do not mean to criticise SQLite or is functionality, it works well for us and has saved us much time in development and test. However we would like to know if it can be tweaked to our specific needs a little. Thanks again. Mark > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 07 June 2006 14:14 > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] disabling rollback journal > > > "Allan, Mark" <[EMAIL PROTECTED]> wrote: > > > > our flash file system is 100% power-fail proof and thus the > > journalling of the database for us is not required. > > > > Without journalling, you cannot have a ROLLBACK command. > And the semantics of UPDATE become UPDATE OR FAIL instead > of the default UPDATE OR ABORT. The difference is subtle, > but important. > > Does your flash file system actually implement atomic > writes of multiple changes changes distributed across > a single file? Or does it just guarantee that each > individual write() is atomic. I'm guessing the latter. > But without the former, you can still quite easily get > database corruption after a power failure if you have > no rollback journal. Any single UPDATE or INSERT or > DELETE command will often result in multiple write() > operations to the database file. If some of those > write()s complete and others do not, your database > will end up in a corrupt state. > > Note that you do not have to take a power failure for > corruption to happen. Suppose a program is writing > to the database, and does 2 of the 5 writes required > to make a change to the database, but then the program > is kill because a different thread in the program > hit a bug and segfaults, or because the program is > sent a SIGKILL (or the equivalent). Without a rollback > journal, the database is left in an corrupt state with > no way to recover. > > In summary, unless you filesystem implements transactions > that span multiple write() requests, you still need a > rollback journal. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > > > DISCLAIMER: This information and any attachments contained in this email message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, forwarding, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return email, and delete the original message immediately.
