Re: Preventing JFFS2 partial page writes?

[Ivan Djelic <ivan.djelic@parrot.com>]

On Wed, Jun 22, 2011 at 04:28:54PM +0100, Peter Barada wrote:
(...)
> 
> I'm thinking a new ioctl (and data in the kernel accessible to the NAND 
> FS layers) is needed (GETOOBLAYOUT?) that returns the oobfree array, as 
> well as other arrays in a structure:
> 1) which OOB bytes perturb the data ECCs,
> 2) which OOB bytes are ECC'd (within the OOB area and separate from the 
> data ECCs).
> 
> I think given the new large-sized NAND that these lists will have to be 
> dynamic (and another GETOOBLAYOUTSIZE ioctl call to return its size) to 
> prevent moving massive structure to userspace).
> 
> Then userspace can figure out:
> 
> 1) what bytes can be written in the OOB.
> 2) what bytes in the OOB can only be written as part of a data write (or 
> sub-page write)
> 3) if no OOB bytes are internally ECC'd(outside of those covered by a 
> data area ECC) then the code needs to either use an ECC as part of the 
> data written to the OOB, or use a bitflip-friendly way to compare the 
> returned data - unless the OOB data it wants to write is part of a data 
> area write.
> 
> In my initial attempt to solve this I ran into the issue (in 
> linux-2.6.32) that nand_transfer_oob/nand_fill_oob make the assumption 
> that chip->ecc.layout->oobfree is *always* zero terminated (I needed 
> eight entries to describe my OOB area).  I'll put together a patch 
> against the latest kernel and send it along.
> 
> Thoughts?

On one hand it sure would be nice (and a bit complicated) to accurately
describe OOB write constraints, for easier JFFS2/YAFFS2 integration.
On the other hand, I am not sure such a complication is really worth the
trouble, given that on next nand generation:
- OOB areas will not be usable anymore for metadata storage (8-bit ecc leaves
  only 6 spare bytes out of 64)
- partial writes will probably be limited to 1 (like in MLC), meaning that
  JFFS2 clean marking step will be forbidden anyway
Furthermore, userspace will probably need to handle case 3) anyway (no
protected oob bytes) to stay portable...

--
Ivan