[Yaffs] Re: Mounting behaviour of YAFFS - how it behaves in time compared to JFFS2?

[Martin Egholm Nielsen]

>>Will YAFFS' worst case scenario be somewhat like the time it takes to
>>perform "dd if=/dev/mtd0 of=/dev/null"? (In my sitation ~20 secs)
> There are some differences between YAFFS1 and YAFFS2 here, so I will split 
> them apart.
> 
> To see this in code form, read yaffs_Scan for YAFFS1 scanning and 
> yaffs_ScanBackwards for YAFFS2 scanning.
> 
> The main difference is that YAFFS1 has deleted tags markers while YAFFS2 does 
> not. This makes the scanning different.

> YAFFS1 scanning looks more or less like:
> 
>   for(all blocks)
>     for(all written chunks in block)
>        read tags (ie read oob/spare)
>        if(!tags.deleted)
>          {
>             if(tags says it is an object header)
>                 read whole chunk to extract file info
>             else
>                 if is a data chunk, insert into tree
>          }
> 
> YAFFS2 scanning looks like:
> 
>   for(all written blocks backwards)
>     for(all written chunks in block backwards
>        read tags (ie read oob/spare)
>          if(tags says it is an object header and we don't yet have file info)

Maybe a silly question: What if a newer version of the object header is 
put in a block at the beginning of the flash - then it will never be read?

>                 read whole chunk to extract file info
>             else if it is a data chunk
>                 if is a data chunk, insert into tree
>          }

> As you can see, in both cases, YAFFS only reads the nand once [well yaffs2 
> also reads one chunk per block to determine if the block is written first].
> YAFFS only makes one pass.
> 
> Most chunks will be data chunks and only the oob/spare needs to be read.
> 
> The absolutely worst case would be a file system that is full of file headers 
> (ie. thousands of zero length files). In this case, the whole nand would have 
> to be read **once**.

And then in addition to that there is also the extensive node-tree 
manipulation in memory (I guess) which may scale differently, depending 
on number of nodes and data-structure strategy (linked list, tree 
structure, etc.)...

>>>BTW: I'm not knocking JFFS2 here, I think it definitely has its place
>>>where space is very limited. The transition point is probably around
>>>16MB, depending of course on application needs.
>>I'm really considering it...
> I cannot force you, but I think you will be happy. Most people that have moved 
> have reported a significant improvement is performance.
Yes, I clearly see a faster read/write access... But I'm still concerned 
about the ECC... Maybe I should try yaffs2?!

// Martin