[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] Database corruption on Linux ext3
From:       Simon Slavin <slavins () bigfraud ! org>
Date:       2010-07-14 3:24:56
Message-ID: 77CF6406-3566-4E6E-8A72-E6EAA9F03013 () bigfraud ! org
[Download RAW message or body]


On 14 Jul 2010, at 1:30am, Jim Wilcoxson wrote:

> This problem of not doing writes, or doing them in
> the wrong order, is a different animal IMO.

If writes are not happening, or are happening in the wrong order, you're in trouble.  \
It's almost impossible to figure out how to even detect that hardware problem without \
a time-consuming scan of each unit that should be written which, in SQLite, means \
reading every page.  Since SQLite doesn't run a server process, it has no opportunity \
to use slack time to check integrity.

Under the conditions described on the web page, this problem can happen only because \
of a power failure or an OS (not an application) crash.  Under these conditions, the \
ext3 file system doesn't support ACID at all: any system that relies on ACID is not \
going to work.  And if the file system doesn't support ACID, the software can't.  I \
don't see any fast way of solving that kind of problem.

It might be useful to figure out whether we're aiming for detection or correction.  \
By 'correction' I don't mean recovery of all information, I mean restoring the \
database to some state it was in just after a COMMIT took effect.  There's no point \
in implementing a detection system if the users consider "This database is corrupt" \
something worth complaining about.  On the other hand, implementing a correction \
system may well slow down every write operation and perhaps '_open' too.  It's not \
worth doing that if slowing down SQLite will decrease usability.

Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


[prev in list] [next in list] [prev in thread] [next in thread]