[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NAND flash and JFFS(2)
On Wed, 6 Feb 2002, Thomas Gleixner wrote:
> The ECC hardware does not limit us to one write. The ECC hardware just
> calculates the ECC if requested and you must read it back out of the CPLD.
> Then you program it into the spare area. On read you must also enable the ECC
> hardware, read the page, read the ECC .... You can do also read/write without
> ECC.There are no restrictions which part of the spare area to use.
True - but in order to implement ECC we have to either write partial
blocks _without_ ECC, until we fill the block and write the ECC data with
the 512nd byte, or batch the writes into pages.
> Should i put them into CVS to jffs-nand-branch or send them by mail ?
Mail's probably best at this stage - thanks.
> > OK. It would be nice if we could trigger GC to fill the wbuf, rather than
> > padding - and only pad it if we really can't use up the space with GC
> > writes.
> Sure, but we must have something, that makes sure that data is written
> immidiatly to the flash, if we have sensitive data loggers or configuration
> data, where a loss is not acceptable.
We can do that. Triggering a GC pass to try to fill the wbuf won't take
long - it can be done in the context of a fsync() call, and if we can't
find anything else to write out, _then_ we pad it and still return
We probably need to rethink our (ab)use of the s_dirt member of the
superblock, and actually make write_super() do the sync too.
> Another thought about cleanmarker nodes. If we keep them in the page, we can
> easy burn a jffs2-image into a raw flash. This makes life easier for
Bootloaders need to know about JFFS2 anyway - currently they erase
blocks without putting a cleanmarker in, then Linux will re-erase all
those blocks again on first mount.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org