On Mon, May 27, 2013 at 10:59:25AM -0500, Thanumalayan Sankaranarayana Pillai wrote: > Hi Woody, > > If the log messages that you see are "chunk nnn not erased", it might > probably be an error between your NAND device and YAFFS2 (according to a > couple of Google searches). > > Ref: http://osdir.com/ml/linux.file-systems.yaffs/2006-09/msg00033.html > > -- > Thanu >
Thanks for the link. How do you guys think about this: if NAND has an IO problem, Yaffs2 should recover it or forward the error to applications, right? Otherwise, I cannot understand what's the right responsibilities of a fs or device driver. > > On Mon, May 27, 2013 at 10:22 AM, Woody Wu <narkewo...@gmail.com> wrote: > > > 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 > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- woody I can't go back to yesterday - because I was a different person then. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
