> -----Original Message-----
> From: Wookey
> Sent: 15 December 2006 14:08
> To: Stoltz Douchet, Olivier
> Cc: yaffs@stoneboat.aleph1.co.uk
> Subject: Re: YAFFS2 and spare bytes usage
> 
> On 2006-12-15 11:34 +0100, Stoltz Douchet, Olivier wrote:
> > Hello Wookey,
> > 
> > I do not know if you remember me, but we met some time ago during a 
> > Linux Expo in London.
> 
> Hi, yes. Best to have this discussion on the YAFFS list, 
> where other experts can weigh in.
> 
> > Anyway, I have a few question regarding YAFFS2 and NAND flash spare 
> > bytes usage.
> > 
> > Correct me if I am wrong:
> > 
> > - it appears that YAFFS2 is currently the only FFS that extensively 
> > uses the spare bytes of NAND flash devices, other FFS such 
> as JFFS2 on 
> > Linux leave this spare byte area almost only to ECC (at the 
> noticeable 
> > exception of their clean marker). Is that correct or do you 
> know any 
> > other FFS in any OS that extensively uses the spare bytes?
> 
> That is correct. (this has given us a certain amount of 
> hassle with changes in MTD and OOB usage, as they only affect us).
> 
> > - you noted that "YAFFS applies the ECC itself, so the MTD 
> should not 
> > do this", how would you then make use of hardware ECC calculation, 
> > which is now often found in SoCs such as our OMAP chips?
> 
> That is out of date. yaffs can do its own ECC (for simple 
> systems where there is no MTD or hardware assistance), or it 
> can let some other hard or software system do it - then you 
> just have to make sure everyone agrees who is dealing with 
> which bytes.
> 
> > Besides, our hardware
> > ECC calculation hardware generates 13 bytes per 512 bytes 
> of data thus 
> > leaving only 6 bytes (32-13*2) of unused spare bytes in 
> case of 1 kB 
> > chunks or 12 bytes (64 - 13*4) of unused spare bytes in 
> case of 2 kB 
> > chunks;
> 
> Hmm, that's not much. yaffs conventially needs 8 bytes for 
> tags, and one for block status, but that can be pared down 
> somwehat at the expense of reducing maximum limits (e.g. file 
> size), or making things a bit less efficient.
> 
> > - I also want to draw your attention to the issue that 
> arises between 
> > your statement "Each page only gets written to twice (once when 
> > written and once when discarded)" and the latest MLC parts 
> that only 
> > guarantee (and allow) a single write to a page. I do not 
> know if you 
> > have already considered these issues.
> 
> We are aware of trends in NAND away from exposing the OOB and 
> reducing page writes. YAFFS will adapt accordingly - there is 
> already a plan to let it not use the oob at all for chips 
> where it is not available. Not sure about the 
> single-page-write. Charles?

I guess that I found the answer on Wikipedia
(http://en.wikipedia.org/wiki/YAFFS):

"YAFFS2 is similar in concept to YAFFS1, and shares much the same code;
and the YAFFS2 code base supports YAFFS1 data formats through backward
compatibility. The main difference is that YAFFS2 needs to jump through
significant hoops to meet the "write once" requirement of modern NAND
flash."

BR

O.