UBI/UBIFS: dealing with MLC's paired pages

[Boris Brezillon]

Hi Karl,

On Thu, 24 Sep 2015 01:57:41 +0000
Karl Zhang 张双锣 (karlzhang) <karlzhang at micron.com> wrote:

> Hello
> 
> Actually, we are working on the paired pages problem too. We have on MLC 
> chips and developed a hardware power control board to simulate the real power loss cycle.
> 
> We have many ideas to share with you.
> 
> 
> 1. emulating the paired-page case
> 	HW: Develop a power control daughter board to control the power supply to NAND, including voltage/ramp control.
> 	SW: Add a module in NAND controller, utilize power board to shut down NAND power when programming paired upper page.

Even the SW solution sounds like a HW solution to me :-).
When I say SW emulation, I mean something that doesn't require a reboot
or power-off operation.

> 		
>  This is easy for us to reproduce paired-page case, in order to guarantee the power loss moment, we add use FPGA logic 
> to control the power board and detect the status of NAND.

That's not so easy for me ;-).
Anyway, as I answered to Andrea, testing on real HW is definitely
necessary, but doing it while evaluating the different options is not as
efficient as emulating paired pages behavior.

> 
> 
> 2. EC/VID header corruption
> 	As Boris's excellent summary mentioned, "duplicate the EC header in the VID header", I also believe this is a good 
> 	solution to protect EC, and we are doing this and testing on MLC.
> 	
> 	For VID header, I think skip pages will waste too many capacity, and SLC mode conjugation with GC will make PE cycling higher.
> 
> 	We are developing another solution to store VID info into other page's OOB area in its own block, because UBI does not 
> 	use OOB and ECC code always not use all OOB area. 
> 

Hm, using the OOB area to do that is not such a good idea IMO, and I see
at least 2 reasons:

1/ You're supposing that you'll always have enough space to store the
VID info (the header is currently taking 64 bytes, even if we could
compress it by removing the padding), and this is not necessarily true
(particularly with some NAND controllers which are allowing as much
space as possible for ECC bytes).

2/ Most of the time ECC bytes are not protected (and even if some
controllers are able to protect a few of them, we're not sure to have 64
bytes of protected OOB bytes per page), which means you're writing
something that can be corrupted by bitflips. I know that the header is
protected by a CRC, but that won't help recovering the data, just let
you know when the header is corruption.
To summarize, you'll have to duplicate the VID info in all pages, and
you're not guaranteed to have a valid one (even if, the more pages you
write the less chance you have to get all of them corrupted)

Regarding the fact that you'll have to at least loose/reserve one page
to protect the VID info, I actually had another (crazy?) idea (which I
didn't expose in my previous mail, because I thought it would be a major
change in the UBI design):
How about completely getting rid of the VID header and relying on the
fastmap database (not the current one, but something close to it) + a
UBI journal logging the different changes (PEB erase, LEB map, ...).
This way we should be able to recover all the information (even the EC
ones) even after a power cut. Of course, still remains the problem of
the fastmap volume corruption.

> 
> 
> We are still developing and testing these solutions to protect EC and VID on MLC.

Okay, let us know about the results. Also, can you share the code
publicly, or is this something you want to keep private until you have
a stable version?

> 		
> 
> All the above is my limited work on paired pages, and I am open to any new suggestions and cooperation.

Thanks for sharing your ideas.

Best Regards,

Boris

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