detect and manage power cut on MLC NAND

[Qi Wang 王起 (qiwang)]

Hi Iwo,

On Fri, 20 Mar 2015 2:52 PM +1100 Iwo Mergler wrote:
>	
>On Fri, 20 Mar 2015 16:07:07 +1100
>Qi Wang 王起 (qiwang) <qiwang at micron.com> wrote:
>
>> Hi Iwo,
>>
>> Glad to talk you here, actually I already talked with Boris about
>> MLC NAND power loss recovery in another email loop couple of days
>> before.
>>
>> I am Micron Shanghai Embedded business group SW leader, in charge
>> Of SW develop, include mtd driver and filesystem optimization.
>>
>> I talked with Boris, I submitted a patent to prevent pair page
>> corruption after power loss in April 2014. And now, I am
>> considering to contribute it to Linux community (still need to
>> align with Micron patent committee) if all of you think this patent
>> is valuable to implement to UBIFS.
>>
>> The basic concept still is backup method, detail as below-
>>
>> 1. When program low page, utilize multiple plane method to
>>    program low page to target address and another backup block.
>>    Barely has performance downgrade even program 2 pages because
>>    of multiple plane feature.
>> 2. when program upper page, no need to backup lower page at all.
>>
>> This method nearly don't have performance penalty compare to before.
>> But need implement multiple plane function, and need to keep
>> the backup block safe to ensure the backup low page data is good
>> when program relevant upper page.
>>
>> How do you think about this idea?
>
>Hi Qi,
>
>it sounds like a worthwhile improvement to the backup to log method.
>I have a few questions.
>
>If I understand you correctly, this method takes advantage of
>the odd/even block planes and the simultaneous multi-plane write.
>
>Do you have to send the page data twice? Or can you apply the
>same page buffer to both planes?

For Micron MLC NAND flash, yes, need to send page data twice. 
But for program operation, the busy time is longer than data
transfer time. 

So the time use multiple plane to program 2 pages of different 
planes almost equal to single plane to program 1 page @ 166MHz 
DDR Sync mode.
If under 50MHz Async mode, multiple plane need a little longer
time than single plane operation. 

>
>If you are about to write the low page in a, say, even block,
>you need find an odd block with the same page available and write
>the same page content to both. I understand that the column
>addresses have to be identical - is that correct?

Yes, correct.

>
>I seem to remember a requirement to write pages to a block in a
>monotonic fashion (low to high). Is that still the case? It
>seems that the low page backup could violate that rule otherwise.

Yes, pages need to be programmed from low to high. But it is possible
to skip some pages. Take a example,

below page program ordering is ok.
Page 0, page 1, page 2, page 4, page 6, page 10, page 15, etc..
Just make sure don't turn back to program the low page is ok.

>
>How would you deal with the backup blocks? The backup must stay
>in place after writing the low page, but only to the moment the
>corresponding high page is written. After that, it's obsolete.

Yes, the backup data should be keep available until corresponding
high page is written. 

>
>Do you envision to dedicate some blocks for this purpose? Or
>would the duplicated pages become part of normal storage blocks?

I don't want dedicate some blocks for this purpose, in this way,
these blocks P/E cycle could increase quickly. 

My idea is to allocate low P/E cycle block from UBI block pool 
when need backup data. And release this block to UBI block pool
when the backup data isn't available any more.

>
>Naively, I see the cost of this method to be somewhere between
>a 25% reduction in storage or a 25% increase in erase cycles,
>depending on the backup block handling.
>Does that match your own prediction?

I think it depends on UBI/UBIFS behavior. 

For example, 

Condition 1 - UBI/UBIFS write a lot blocks partially
The UBI/UBIFS write order like below:	
Program some pages in block0, then block1, block2,3,4,5,6...100..
Then, UBI/UBIFS turn back to program block0,1,2... again. 
	
I think this condition need many backup blocks, as a lot data will
be available at some time. right?


Condition 2 - UBI/UBIFS only write several blocks partially
The UBI/UBIFS write order like below:	
Program some pages in block0, then block1, block2, 3. 
Then, UBI/UBIFS turn back to program block0,1,2, 3. Until one of the
blocks is full, UBI/UBIFS will open block4, and write data into it.

In this condition, we can only allocate 4 blocks to backup block 0,1,2,3
data should be ok. Right?


For my understanding, UBI/UBIFS behavior is more like condition 2. 
Except EC header written, EC will be written into block initially. 
So I don't suggest use this method to backup EC.

And also, some of operation don't need to backup operation, such as,
Wear leveling, refresh etc..

Am I wrong? Please kindly prove it.

--
Qi Wang

Thanks