jffs2/nand flash
John Stirling
js at reciva.com
Thu Dec 11 04:42:05 EST 2003
I've done some further investigation on this.
The problem I was seeing was caused by a call to jffs2_full_dnode (in
write.c, alloc_mode=ALLOC_GC). This leaves stuff in the write_buf, but
never gets round to actually writing it to flash unless another write
happens in the meantime.
When I copy a file the flushing procedure seems to work. I see an
initial page write, followed a couple of seconds later by another write
of the remaining stuff in the write_buf. However, following this, more
stuff remains in the write_buf, which again never gets written to flash
and produces errors again when the kernel is rebooted.
As an experiment i removed the checked for ino!=0 at the end of
jffs2_flash_writev
ie
replaced
if (c->wbuf_len && ino)
jffs2_wbuf_dirties_inode(c, ino);
with
if (c->wbuf_len)
jffs2_wbuf_dirties_inode(c, ino);
Having done this, almost all the reported errors disappeared next time I
rebooted.
Also, I noticed that having copied a few files manually then some of the
errors disappeared.
So, is it possible that the errors that are being reported are not
really errors and will get cleaned up via garbage collection at some
point. If so, then it would be nice if they weren't reported are
errors..
On Wed, 2003-12-10 at 13:07, John Stirling wrote:
> > Not fsync() but a flush should happen then, yes.
> >
> > Compile with CONFIG_JFFS2_FS_DEBUG=1. Run 'sync' after writing your
> > file. Show me the output.
> >
>
> See extract from kernel log below. Setting FS_DEBUG=1 didn't seem to
> produce any more debug info. sync didn't cause a further page write..
>
>
>
More information about the linux-mtd
mailing list