Richard,

If Yaffs2 is the cause, how can I write an effective test to exposure it?
 I straced my test sqlite test program and wanted to understand its IO
behavior pattern.  The difficulty is that I cannot run strace on my ARM
target too long since the log will fill the limited memory, but if I don't
run it enough long, I am not sure it expressed enough information. By far,
as what I saw in my strace output after serveral minutes running of the
program, I only saw a lot of llseek() + write() paire on the main database
file as well as its journal.  From your understanding of sqlite, could you
tell me what's the file IO pattern as result of running the test program?

By the way, although my test code contains a logic to delete some records
after the table have already filled with enough many rows, but many of my
tests results shown that the database corruption happened before the delete
operation get chance to run.  Maybe this can simply you analysis.

Another thing is very suspicious:  after a while of running the test
program, I can see from my syslog that there are a log of warning messages,
something like: Yaffs2 trunk nnnn was not erased.  On one hand, I am not
sure if this is caused by sqlite or Yaffs2 itself, on the other hand, I
also cannot prove this really means bad things since the program at that
moment was still running fine.

-woody




On 27 May 2013 20:47, Richard Hipp <d...@sqlite.org> wrote:

> On Mon, May 27, 2013 at 8:28 AM, Simon Slavin <slav...@bigfraud.org>
> wrote:
>
> >
> > On 27 May 2013, at 1:25pm, Clemens Ladisch <clem...@ladisch.de> wrote:
> >
> > > Woody Wu wrote:
> > >> I have a testing code, attached in this email, if continuously run it
> > for
> > >> 20 - 40 hours, the sqlite database will be corrupted.
> > >>
> > >> The application is running on an ARM Linux system with Yaffs2
> filesystem
> > >> on NAND flashes.
> > >
> > > I'd guess that the flash is not very reliable.
> >
> > I test on Flash drives.  No problems.  But I don't use yaffs2, I use FAT
> > and HFS+.  I'm not saying there's anything wrong with yaffs2.
> >
>
> (1) Do a web search for "counterfeit flash".  There are a lot of dodgy
> flash drives and flash memory chips in circulation.  Simon might be using
> good chips whereas Woody might have a bad one.
>
> (2) I'm less willing to give yaffs2 a pass.  Yaffs2 bypasses much of the
> common filesystem code in the Linux kernel and attempts to do its own
> thing.  This has been a persistent source of issues. I recommend that Woody
> try Ext4 instead.
>
> All that said:  I have compiled Woody's test program and am running it now
> on a Linux workstation.  We'll see what happens after 40 hours....
>
> --
> D. Richard Hipp
> d...@sqlite.org
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
Life is the only flaw in an otherwise perfect nonexistence
    -- Schopenhauer

narke
public key at http://subkeys.pgp.net:11371 (narkewo...@gmail.com)
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to