Hello Charles, On 3/4/07, Charles Manning 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. > > f) YAFFS doesn't implement any wear levelling AFAIK which is a minus. > 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. Vitaly