detect and manage power cut on MLC NAND

[Qi Wang 王起 (qiwang)]

Hi Boris,

On Fri, 20 Mar 2015 04:58:24 PM +0000 Boris Brezillon wrote:
>
>Hi Qi,
>
>On Fri, 20 Mar 2015 07:44:58 +0000
>Qi Wang 王起 (qiwang) <qiwang at micron.com> wrote:
>
>> >
>> >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.
>
>I asked a question regarding the programming sequence in answer to Iwo,
>but I'm not sure you were in Cc, so I'm asking it again.
>
>Say page 1 is paired with page 4, can we program pages in this order:
>1, 4, 2, 5, 3, 6, ..., so that both paired pages are programmed
>together (the Jumbo page approach Iwo described in his mail).
>
>
>[...]
>>
>> >
>> >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.
>
>But you can't take a random PEB: it has to be an even or odd block
>number depending on which block the page you're trying to backup
>belongs to, right ?

Yes, actually I strongly suggest to record plane information of
a block in UBI.
   
For SLC NAND, we can merge 2 physical blocks belong to different 
plane to 1 logic block, and logic page also contain 2 pages belong 
to these 2 physical. That mean logic block size and page size are 
twice than before. Then, we can use multiple plane method to program
this 2 physical pages, to improve performance. Right?
However, this is another topic related with performance.

>
>>
>> >
>> >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?
>
>It depends on how you deal with it, but if you're assigning a backup
>block for each payload/data block, then you'll have the same number of
>backup and data blocks, until some data blocks are completely filled
>with data.
>
>>
>>
>> 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?
>
>I would say so. IOW, you're loosing half your NAND capacity in the best
>case, right ?
>

Yes, very painful. :)
But if it is possible to occur this best case? And if we can avoid this 
happen?


>BTW, where do you store information about where each block store its
>lower pages backup ?
>

For my rough idea is, we can store address in OOB area of the page.
In the UBI software framework, it reserve some "internal volume", we 
can leverage this mechanism to create a internal volume to manage these 
backup page. 
During attach process, we can find this backup volume, and check if 
backup data is equal to the original data. 
Anyway, this is my rough idea, still need to talk with all of you.   

>>
>>
>> For my understanding, UBI/UBIFS behavior is more like condition 2.
>
>Yep, that's my understanding too, but I'm definitely not a UBIFS expert.
>

I ever did simple experiment on UBIFS, to random create/write/modify 
files or directory. I found UBIFS behavior is like condition 2. 
But I don't know if my experiment cover the worse case, so need experts 
to confirm me.  


>> Except EC header written, EC will be written into block initially.
>> So I don't suggest use this method to backup EC.
>
>It depends. If you want to write on the pages paired with EC and VID
>headers, you'll have to somehow same EC/VID information.

Sorry, I'm not very clear this point. My understanding is VID contain 
the mapping information that from physical to logical, right? This
information will be written only when UBI allocate a new logic block.
So it is ok to backup this VID data to backup block.

But for EC, it will written all block's page 0 at the format period.
My backup low page method isn't suitable for this operation, as it is 
the worse case you mentioned above, that will lose half of NAND 
capability, right? 

>
>>
>> And also, some of operation don't need to backup operation, such as,
>> Wear leveling, refresh etc..
>
>That's true for the wear leveling part (and for all atomic LEB
>operations in general), because a CRC is calculated and stored in the
>VID header, so that data integrity of the whole LEB can be checked.
>
>What do you mean by refresh ?

The refresh I mentioned is when bit flip count exceed the threshold, UBI will
move available data to another block. :)

--
Qi Wang
Best wishes