On 3/2/07, Charles Manning <manningc2@actrix.gen.nz> wrote:

> 1) YAFFS uses less run-time RAM to hold its state so YAFFS scales better than
> JFFS2. There are quite a few systems using large NAND arrays (the largest
> partitions I know of are around the 6Gbyte mark).
>
> 2) YAFFS garbage collection is simpler and faster typically making for better
> performance under hard writing.
>
> 3) YAFFS uses a whole page per file  for headers, and does not provide
> compression. This means that JFFS2 is probably a better fit to small
> partitions.  The flip side though is that a lot of data (eg. MP3) does not
> compress very well and enabling compression really hurts performance.
>
> 4) While YAFFS has been used on NOR, it does not fit that well (because YAFFS
> does not use erase suspend). Thus if you're using smaller NAND partitions and
> using jffs2 on NOR, then a jffs2-only solution is very appealing.

Absolutely agreeing with Charles on these points, I'd like to add a
couple of cents.

a) YAFFS2 is not in the mainline, thus gaining less testing/support
from the open-source community
b) but YAFFS2 code is generally simpler than that of JFFS2, so once
you're in a trouble debugging something, you'll probably cope with it
faster with YAFFS2
c) YAFFS2 extensively uses OOB area which might make it unusable with
some NAND controllers taking a lot of OOB space for ECC, and with some
types of NAND flash (e. g. OneNAND)
d) YAFFS2 is likely to be slower with bitbanging NAND due to hard OOB usage
e) YAFFS2 supports a lot of legacy kernels which is probably a plus
for the most cases
f) YAFFS doesn't implement any wear levelling AFAIK which is a minus.

Thanks,
   Vitaly