This is a real Sqlite error, in http://www.sqlite.org/c3ref/c_abort.html, there is: #define SQLITE_IOERR 10 /* Some kind of disk I/O error occurred */ This error occurs when a seek()/read() call fails.
That's why I've analyzed the journal file and decoded its header: the page nb differ from the real page stored in the journal. So, seek() generates a kind of "out of file" error. "PRAGMA integrity_check" is just a little sqlite level command that demonstrate the issue, but the application is crashing every time it tries to read the database. I think it's a real issue between Sqlite and FS. Sqlite has huge constraints against FS behavior: "If a Linux ext3 filesystem is mounted without the "barrier=1" option in the /etc/fstab and the disk drive write cache is enabled then filesystem corruption can occur following a power loss or OS crash. Whether or not corruption can occur depends on the details of the disk control hardware; corruption is more likely with inexpensive consumer-grade disks and less of a problem for enterprise-class storage devices with advanced features such as non-volatile write caches. Various ext3 experts confirm this behavior. We are told that most Linux distributions do not use barrier=1 and do not disable the write cache so most Linux distributions are vulnerable to this problem. Note that this is an operating system and hardware issue and that there is nothing that SQLite can do to work around it. Other database engines have also run into this same problem." Emmanuel. -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Simon Slavin Sent: Tuesday, September 20, 2011 2:08 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Disk I/O Error on Ext3/write-back/barrier FS. On 20 Sep 2011, at 9:43am, Berthier, Emmanuel wrote: > I'm using Sqlite 3.6.22 Froyo Branch on Android 2.3.4 distribution on a > handset with eMMC storage memory. > In case of power-cut (battery removal or kernel panic), we encounter some > rare but critical errors during database rollback sequence: journal file is > corrupted: > # sqlite3 contacts2.db > sqlite> PRAGMA integrity_check; > PRAGMA integrity_check; > Error: disk I/O error Here are all the SQLite result codes: http://www.sqlite.org/c3ref/c_abort.html As you can see they're about formatting and files. 'disk I/O error' isn't a SQLite result code, I think it may be a sign that your hardware is faulty. One thing that "PRAGMA integrity_check" does is read a lot of the file very quickly. It doesn't read every byte of the file but it does read a lot of the file and do some intense processing. So it's a good way of putting storage, memory, databus and CPU under load. I think there's a chance that this is betraying some underlying fault with your hardware. Perhaps you have some benchtesting software you can run on the same unit. Something that does a bunch of processing and writing and reading of files but doesn't involve any SQLite ? Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
