> Hello Charles,
>
> On 3/4/07, Charles Manning <manningc2@actrix.gen.nz> wrote:
>> > a) YAFFS2 is not in the mainline, thus gaining less testing/support
>> > from the open-source community
>> This is possibly true, but I don't think that it ncessarily follows.
>> Just
>> because stuff is in the mainline does not mean it is well tested. I have
>> found more than one driver in the mainline that got broken due to a
>> kernel
>> change impacting on a driver.
>
> Yes, that's certainly true. Still if yaffs2 were in mainline, more
> people would have been using/testing it. That actually was my point.
>
>> > d) YAFFS2 is likely to be slower with bitbanging NAND due to hard OOB
>> usage
>> Can you explain that a bit more. I don't understand what point you are
>> trying
>> to make.
>
> YAFFS2 uses OOB area more intensively than JFFS2, so in order to
> read/write things it issues more NAND commands generally, which turns
> to be a performance drop for GPIO/bitbanging NAND controller
> emulation.

This should not be the case.
YAFFS2 writes NAND (data + tags) as a single operation. The driver should
be performing a single write to NAND. If not then something is broken.
With JFFS2 you still need to write the the ECC to oob, so both YAFFS and
JFFS2 should not require a different number of commands for a nand write
operation. The only material difference is that YAFFS needs more oob bytes
transfered as part of the write operation.

ie: Disregarding deeper fs issues and just focussing on the NAND writing:

JFFS2 write
CMD: Set up data write
copy data into buffer
CMD: Set up oob write
copy ecc into buffer
CMD: program page

YAFFS2 write
CMD: Set up data write
copy data into buffer
CMD: Set up oob write
copy ecc + tags into buffer
CMD: program page

They only differ in the copying of the tags. The actual commands are
unchanged. Since the tags are somewhat equivalent to JFFS2 "meta-data",
JFFS2 is storing it anyway - just in a different place.



>
>> > f) YAFFS doesn't implement any wear levelling AFAIK which is a minus.
> <snip>
>> If is true that YAFFS does not do any explicit wear levelling. Instead,
>> a
>> degree of wear levelling is a side-effect of how free blocks are
>> managed.
>> Although the code and motivation is entirely different, the result is
>> similar
>> to how the SmartMedia/SD free is managed but the pool is typically far
>> larger
>> for YAFFS meaning that the wear levelling is far better.
>>
>> To explain that last statement a bit: In a FATfs on SmartMedia/SD,
>> typically
>> 1000 out of 1024 blocks are formatted and in use and the free pool is
>> only 24
>> blocks (reduced by the number of bad blocks) this makes the pool
>> relatively
>> small meaning that the averaging effect is only scattered over a few
>> blocks
>> at a time. In other words: a formatted block is "in use" whether it
>> holds
>> data or not. In YAFFS, blocks that do not contain useful data are unused
>> and
>> in the free pool. This means that the free pool is typically far bigger
>> and
>> the averaging effect is better.
>
> Thanks for the explanation, I must admit myself being wrong here.

That's fine. We're all learning stuff all the time :-). The infrequent
mistake is the very small price we pay for your valuable contribution

-- CHarles