UBI/UBIFS: dealing with MLC's paired pages

[Boris Brezillon]

Hi Bean,

On Fri, 25 Sep 2015 08:25:44 +0000
Bean Huo 霍斌斌 (beanhuo) <beanhuo at micron.com> wrote:

> > Bean Huo 霍斌斌 (beanhuo) <beanhuo at micron.com> wrote:
> > 
> > > > And 3:
> > > > Only NAND provides an OOB area. Other flash devices like parallel or
> > > > SPI NOR don't. And we definitely want to continue supporting
> > > > platforms with such flash devices and UBI (and UBIFS).
> > > >
> > > > Thanks,
> > > > Stefan
> > > >
> > > For MLC NAND paired pages issue, we have developed two methods to
> > > solve it in UBI layer, We hope that every expert on UBI/UBIFS can give more
> > suggestions about how to improve and perfect it.
> > > I think ,this week, I can submit first solution patch out. Currently do coding
> > style.
> > 
> > Are you referring to the suggestion proposed by Karl (using the OOB area to
> > store UBI metadata), or is this something else?
> > 
> > Best Regards,
> > 
> > Boris
> > 
> > --
> > Boris Brezillon, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
> 
> Hi, Boris
> For NAND OOB area, it is dedicated for ECC value, at the same time,
> User available area in OOB is not covered by ECC protection mechanism.
> so saving EC or VID information in OOB is not a perfect solution.
> But if there is additional space, and this space can be covered by ECC,
> We can try it.

The problem is, we want the solution to be as generic as possible, and
not all NAND/ECC controllers are able to protect OOB bytes :-/.

> By the way, I want to allocate a new internal volume to solve paired pages issue.
> How do you think about this ?

I actually had a similar idea, but instead of creating a new metadata
volume, I wanted to reuse the fastmap one.
My idea was not to duplicate data from already programmed pages in
this volume (not sure this was your idea either, could you tell us
more about what you had in mind?), but instead use it to log UBI
operations like
- PEB erasure: to save the EC counter and recover it if a power-cut
  occurs after the erasure but before the EC header is written to the
  block. Doing that would also partly solve the 'unstable bits' issue,
  since we would be able to know which block was being erased before
  the power-cut occured.
- LEB map: to save the lnum <-> pnum association and recover from VID
  header corruption.
- Last written block (still not happy with that): to log on which block
  the last write operation has taken place. This would help solving the
  'unstable bits' problem, but it would also add a non negligible
  overhead if writes are not consecutive (not done in the same LEB)

Other ideas are welcome.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com