JFFS2 an nodes checking

[Josh Boyer]

On Tue, 2004-09-28 at 11:48, Artem B. Bityuckiy wrote:
> > Yes, he does. The problem is that each time you access a FIFO you update
> > its ctime and mtime on the flash... which leads to a _lot_ of nodes,
> > only one of which is non-obsolete. That's a problem on NAND flash.
> 
> Things are same for regular files. This is from SUSv3 for write() call:
> 
> "Upon successful completion, where nbyte is greater than 0, write() 
> shall mark for update the st_ctime and st_mtime fields of the file"

Yes, but in that case you are writing data anyway.  So updates of
st_ctime and st_mtime are free.

> 
> This is from SUSv3 fore read() call:
> 
> "Upon successful completion, where nbyte is greater than 0, read() shall 
> mark for update the st_atime field of the file, and shall return the 
> number of bytes read."

I think we have the "noatime" mount option to avoid this for JFFS2.  Or
some similar mount flag.  I don't remember offhand.

> 
> What's special with FIFOs ?

Fifos don't really hold data, they are just named pipes.  When you write
to it, it's mostly handled by the VFS.  The actual data isn't written
out by JFFS2.  Except that we have to update st_ctime and st_mtime,
which causes more nodes.

> 
> Why that's a problem on NAND flash especially ?

Because you can't directly obsolete a node on NAND flash (and some weird
versions of NOR flash as well).  So obsolete nodes are actually written
out to flash instead of just flipping a bit in the existing node.

josh