Re: detect and manage power cut on MLC NAND

[Boris Brezillon <boris.brezillon@free-electrons.com>]

Hi Qi,

On Fri, 20 Mar 2015 07:44:58 +0000
Qi Wang 王起 (qiwang) <qiwang@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 ?

> 
> >
> >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 ?

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

> 
> 
> 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.

> 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.

> 
> 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 ?

Best Regards,

Boris

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