Re: [Yaffs] Re: Products shipping YAFFS ??

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.