Hi,
Thanks you for your response, that is really helpful. Actually, I will
do completely the other way, so setup my database with frequent
checkpoints and process exiting occasionally, but for test purposes to
track the issue down. At the moment the problem is hardly reproducible
(one occurrence per hundreds resets), but your advise should give me
more reproducible scenario. I suspect some synchronization issue on very
low lever driver, involving interrupts from the SD controller. If anyone
have another idea how to improve this test and make the corruption more
possible, that would be great.
Regards,
Greg
On 11/04/14 12:22, Richard Hipp wrote:
On Fri, Apr 11, 2014 at 6:55 AM, Grzegorz Sikorski
<g.sikor...@kelvatek.com>wrote:
Hi Richard,
We do fsck on the startup. Occasionally, there are some errors, so we
decided to do 'fsck -p' to fix them before mounting the filesystem. Here is
how we then mount the actual filesystem:
/dev/mmcblk0p2 on /media/DATA type ext4 (rw,relatime,barrier=1,
journal_checksum,nodelalloc,data=journal,usrquota)
I am not an expert in ext4, so I am not sure it is the best way to mount,
but as far as I read on some forums, this is the safest (and slowest!)
option.
If EXT4 is also corrupting, that is evidence to support my theory that the
SD card is not synching correctly and is performing writes out of order.
And if that is the case, then there is nothing you can do to prevent
corruption on power-loss, to SQLite or any other database. All you can do
is try to minimize your exposure.
(1) Using WAL mode is good. But the usage pattern makes a difference
too. Please make sure you have at least one process that opens the
database (in WAL mode) and keeps it open all the time. That processes
doesn't have to do anything with the database other than hold it open.
SQLite deletes the WAL file when the last connection closes. By having one
process hold the database open, that prevents the WAL file from being
deleted, which reduces the risk of corruption.
(2) Make sure you are not checkpointing too frequently. Remember that the
power-loss corruption vulnerability only occurs during checkpoint. You
have to checkpoint *sometime*. Just try to make sure it isn't too often,
so that the risk of taking a power loss during a checkpoint is reduced.
(3) Make periodic backups of the database file using the SQLite backup
API. Then on startup check the database for corruption (using PRAGMA
integrity_check or PRAGMA quick_check) and move to the backup if corruption
is seen.
--
Asylia ExchangeDefender Message Security: Click below to verify authenticity
http://www.exchangedefender.com/verify.asp?id=s3BCvUaq031855&from=g.sikor...@camlintechnologies.com
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
