Hello Chris
On Thursday 14 August 2014 03:49:17 Chris Gofforth wrote:
> Hi:
>
> This post relates to the bit-flip issue threads.
>
>
> It has been suggested that the YAFFS logic be told to do GC on a block
> which contains a page (Chunk) that needs to be moved due to too many Bit
> flips. The idea being that the block should get 'refreshed' to clear the
> bit flip issues and causing a GC in YAFFS2 will do this.
The "core" code to handle this is already written, but the driver integration
is not yet done:
http://yaffs.net/gitweb?p=yaffs2.git;a=commit;h=dba051c0183a6ce9f1af61f9ec2b0f09419e48da
>
>
> In this situation, all pages within the block have to be moved before that
> block can be erased (Since all the data is still valid).
Yes, we must move all pages for a few reasons:
1) In Yaffs2 mode (the primary usage mode),
2) If one page is showing issues, then chances are the whole block is suspect
and prudence suggests we should refresh the whole block.
> For MLC flash,
> this could be a large number ( say 256, 8-16k pages). That means 256 reads
> modify program operations. That time can be considerable.
> Does YAFFS2 only do one or a few page move at a time ( read modify program)
> and then allow other access requests to occur, or does it basically do it
> all at one, meaning that any other access requests are now made pending?
> The 'How Yaffs Works' documentation talks about passive/aggressive methods.
> In this situation ( where we say to do GC due to bit-flip issues) which one
> will it do?
The same passive/aggressive rules apply. All we've done is given the gc
a "hint" to please select this block and do gc on it.
Unless gc is very urgent, Yaffs will normally only gc a few pages at a time.
That is done for the very reason you mention - to prevent the fs being
stalled.
[Sidebar: Some log structured fs need to gc multiple blocks at a time. I have
seen some stall for multiple seconds. Yaffs is not like that.]
>
> This would help us determine how many 'pauses' and how much of a pause we
> can expect when accessing MLC flash.
There will be some pauses, but they should not be noticable. ie we're
typically talking single-digit milliseconds and not seconds.
It is worth noting though that when the fs is completely full, the gc has to
work much harder and "aggressively". That is going to degrade write
performance.
There are two simple mitigation strategies though:
1) Never fill the fs completely. Leave, say a megabyte or two free.
2) Activate the background gc.
Regards
Charles
(text/plain)