Re: Preventing JFFS2 partial page writes?

[Artem Bityutskiy <dedekind1@gmail.com>]

On Fri, 2011-07-01 at 22:48 +0200, Ivan Djelic wrote:
> 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 ?

Yes, I agree, this sounds much saner than trying to teach MTD to
distinguish between protected and unprotected areas. However, if Peter
is able to come up with a really really nice patch-set which adds the
functionality he needs in a nice way (good docs, good code separation,
clean-up of the current stuff, good testing) - why not? But I think he'd
need to do _a lot of_ work to achieve this.

-- 
Best Regards,
Artem Bityutskiy