Re: Preventing JFFS2 partial page writes?

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

On Tue, Jun 28, 2011 at 10:39:47AM +0100, Artem Bityutskiy wrote:
> On Tue, 2011-06-28 at 12:34 +0300, Artem Bityutskiy wrote:
> > OK, thanks for explanation. I am not very good in this area as I do not
> > have much experience dealing with OOB, but here is what I thing.
> > 
> > 1. Linux MTD code was _not_ designed for "ECC'ed OOB".
> > 2. I do not really know what MTD_OOB_RAW is, and the comment in mtd.h
> >    is not very verbose.
> > 3. But in my opinion MTD_OOB_AUTO makes most sense and should be used
> >    everywhere except for some tricky cases when you want to test things
> >    by writing incorrect ECC, or you have an image with ECC and you want
> >    to flash it as is.
> > 4. In general, OOB should be considered as belonging to the driver, and
> >    modern software should not rely on OOB at all.
> > 5. So MTD_OOB_AUTO make free bytes in OOB look like a contiguous buffer
> >    which the _user_ can freely and _independently_ use.
> > 6. In your case only this assumption does not work and your ecclayout is
> >    incorrect because the OOB areas you expose are not independent.
> > 7. So in your case your ecclayout should be changed and you should
> >    expose only independent ECC bytes.
> 
> To put it differently, I current model does not distinguish (I think,
> correct me if I am wrong) between ECC'd OOB bytes and ECC'less OOB
> bytes. BTW, does your flash has the latter?
> 
> So MTD would need some work to make it distinguish between those 2 types
> of OOB bytes - probably additional info could be added to the ooblayout
> structure, and the interfaces could be improved. How exactly - dunno,
> I'd first need to figure out what MTD_OOB_RAW is - may be Brian or Ivan
> could comment.

I agree with the idea that OOB should be considered as belonging to the driver.
I think the problem should be solved as follows:

1. Expose only unprotected (or "independent") bytes in your ecclayout. Those
bytes will be used by JFFS2 for its cleanmarker.

2. Use YAFFS2 "inband-tags" option to prevent YAFFS2 from using oob for storing
metadata.

If for some reason you really cannot use inband-tags, then patch YAFFS2 and add
an option so that it can use MTD_OOB_PLACE instead of MTD_OOB_AUTO, and
store its metadata into a specified list of protected OOB bytes.

Rationale: you would have to configure YAFFS2 for this specific device anyway,
by using YAFFS_DISABLE_TAGS_ECC or tags_ecc_off in order to let nand on-die ecc
protect metadata.

I would rather not add new complexity in mtd ecclayout to solve your problem,
because it is a bit too specific (your client insists on not using UBIFS which
would be better suited for this generation of nand devices) and this new
interface would probably be short-lived (as discussed in
http://lists.infradead.org/pipermail/linux-mtd/2011-June/036549.html).

What do you think ?

--
Best Regards,

Ivan