On Tuesday 06 March 2007 03:18, qwe wrote:
> The "free pool" in YAFFS is larger ,but YAFFS select the block for use is
> the first find  empty block ,if it is more random   i think the performace
> more well ,am I right?

I think by saying "performance"  you are meaning that the performance of the 
wear levelling (ie. the amount of wear distribution) would improve.

YAFFS does not just select the first empty block. It selects the next empty 
block after the one is allocated last time. This causes quite an even wear 
pattern, so I don't think randomising it would really change anything.

Rather than rewrite what I have written before, I will quote from an answer I 
gave to the same question off list (and add some stuff).

> Let's suppose we have a file that is being constantly rewritten each,
> say, minute within the partition that is half emply. YAFFS2 will use
> the same pages for writes again and again, instead of spreading writes
> over the spare part of the partition as it would have done if it had
> wear levelling means.

Not correct.

See yaffs_FindBlockForAllocation().

If you had a partition that was half-full with static data and one small file 
that is constantly being rewritten then the following would happen:
The static files would be left in place.
The small file would be rewritten on different blocks each time. This would 
essentially give you wear levelling over half the space. In other words, half 
the media will be written before the starting block is rewritten.

In YAFFS, the blocks are allocated by going sequentially upward then rolling 
back to the start block. YAFFS remembers where it had got to on the previous 
allocation and starts searching from there. So, if you started with a file 
on, say, block 5 and rewrote it constantly it would then be written on block 
6 then 7 then....  This gives even spreading over the unused blocks. 
Using a randomising function is not going to give better spreading than that.

The one case where I can see randomising helping would be in a system that is 
constantly being rebooted so that dev->allocationBlockFinder is always being 
reset and YAFFS never have a chance to use it effectively. A single 
randomisation of this variable at initialisation would fix that.

On an actively wear levelled system (eg. M-Systems), the static files would 
also get rewritten causing wear levelling over the entire partition, at the 
expense of write speed (more stuff to write).

Let's consider now a SmartMedia "free pool" style wear levelling with FAT file 
system on a device with 1024 blocks. 1000 blocks will be allocated, say 9 
will be bad leaving 15 in the free pool. Now let us also assume that you have 
the above scenario of a half-full media with one small file being rewritten. 
Since FAT will be using the same set of logical blocks, the same set of 
physical blocks will be cycling through the free pool and the blocks will be 
reused much faster.