On Thursday 14 August 2014 07:43:42 Charles Manning wrote:
> 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=dba051c0183a6ce9f1af61f9ec2
>b0f09419e48da
>
> > 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),
Oops... missed a bit:
   In Yaffs2, mode (the primary usage mode), chunks must be kept in their 
original order within a block or the timeline can be messed up.
> 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
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs