RE: detect and manage power cut on MLC NAND

RE: detect and manage power cut on MLC NAND

[Iwo Mergler]

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

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?

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.

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.

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

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?


Best regards,

Iwo

RE: 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@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

Re: detect and manage power cut on MLC NAND

[Boris Brezillon]

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

Re: detect and manage power cut on MLC NAND

[Richard Weinberger]

Am 20.03.2015 um 09:58 schrieb Boris Brezillon:
> 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).

That's a good question. I was always told that you're not allowed
to program pages in a non-linear manner.

Thanks,
//richard

RE: detect and manage power cut on MLC NAND

[Qi Wang 王起 (qiwang)]

Hi Boris, Richard

On Fri, 20 Mar 2015 05:08 PM +0000 Richard Weinberger wrote:
>
>Am 20.03.2015 um 09:58 schrieb Boris Brezillon:
>> 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).
>
>That's a good question. I was always told that you're not allowed
>to program pages in a non-linear manner.
>

Yes, you are right. This method isn't allowed. User can only program page
within a block from low address to high address.

--
Qi Wang
Thanks

Re: detect and manage power cut on MLC NAND

[Boris Brezillon]

Hi Qi,

On Fri, 20 Mar 2015 15:05:54 +0000
Qi Wang 王起 (qiwang) <qiwang@micron.com> wrote:

> Hi Boris, Richard
> 
> On Fri, 20 Mar 2015 05:08 PM +0000 Richard Weinberger wrote:
> >
> >Am 20.03.2015 um 09:58 schrieb Boris Brezillon:
> >> 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).
> >
> >That's a good question. I was always told that you're not allowed
> >to program pages in a non-linear manner.
> >
> 
> Yes, you are right. This method isn't allowed. User can only program page
> within a block from low address to high address.

Do you know the reason behind this ?



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

RE: 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@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

RE: detect and manage power cut on MLC NAND

[Qi Wang 王起 (qiwang)]

Hi Boris,

On Fri, 20 Mar 2015 11:19:48 PM +0000 Boris Brezillon wrote:
>
>Hi Qi,
>
>On Fri, 20 Mar 2015 15:05:54 +0000
>Qi Wang 王起 (qiwang) <qiwang@micron.com> wrote:
>
>> Hi Boris, Richard
>>
>> On Fri, 20 Mar 2015 05:08 PM +0000 Richard Weinberger wrote:
>> >
>> >Am 20.03.2015 um 09:58 schrieb Boris Brezillon:
>> >> 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).
>> >
>> >That's a good question. I was always told that you're not allowed
>> >to program pages in a non-linear manner.
>> >
>>
>> Yes, you are right. This method isn't allowed. User can only program
>page
>> within a block from low address to high address.
>
>Do you know the reason behind this ?
>

I need to inquire our product engineer, will give you answer once I get it.

--
Thanks
Qi Wang

RE: detect and manage power cut on MLC NAND

[Jeff Lauruhn (jlauruhn)]

Hi Boris; 
> Yes, you are right. This method isn't allowed. User can only program 
> page within a block from low address to high address.

Do you know the reason behind this ?
This is done to help mitigate disturbs and to ensure we get the highest reliability.  Driving software developers crazy is just an extra benefit.  :) 


Jeff Lauruhn
NAND Application Engineer
Embedded Business Unit
Micron Technology, Inc


-----Original Message-----
From: Boris Brezillon [mailto:boris.brezillon@free-electrons.com] 
Sent: Friday, March 20, 2015 8:19 AM
To: Qi Wang 王起 (qiwang)
Cc: Richard Weinberger; Iwo Mergler; linux-mtd@lists.infradead.org; rnd4@dave-tech.it; Jeff Lauruhn (jlauruhn); dedekind1@gmail.com; andrea.marson@dave.eu; Bean Huo 霍斌斌 (beanhuo); Frank Liu 刘群 (frankliu); Zoltan Szubbocsev (zszubbocsev)
Subject: Re: detect and manage power cut on MLC NAND

Hi Qi,

On Fri, 20 Mar 2015 15:05:54 +0000
Qi Wang 王起 (qiwang) <qiwang@micron.com> wrote:

> Hi Boris, Richard
> 
> On Fri, 20 Mar 2015 05:08 PM +0000 Richard Weinberger wrote:
> >
> >Am 20.03.2015 um 09:58 schrieb Boris Brezillon:
> >> 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).
> >
> >That's a good question. I was always told that you're not allowed to 
> >program pages in a non-linear manner.
> >
> 
> Yes, you are right. This method isn't allowed. User can only program 
> page within a block from low address to high address.

Do you know the reason behind this ?



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

RE: detect and manage power cut on MLC NAND

[Qi Wang 王起 (qiwang)]

Hi Jeff,

So glad to meet our Micron colleague here. 

On Fri, 21 Mar 2015 12:48:35 AM +0000 Jeff Lauruhn wrote:
>
>Hi Boris;
>> Yes, you are right. This method isn't allowed. User can only program
>> page within a block from low address to high address.
>
>Do you know the reason behind this ?

For this method, my idea is we can consider page 1 and page4 as one 
page, to program page 1 and page 4 together. So if power cut occur, 
both page 1 and page 4 (But one page corruption in software view)will 
corrupt at same time, won't have issue for UBI/UBIFS.

I am not sure if I am right, Boris can correct me. 

>This is done to help mitigate disturbs and to ensure we get the highest
>reliability.  Driving software developers crazy is just an extra
>benefit.  :)

Yes, I agree this point, to mitigate disturbs. 

--
Thanks
Qi Wang

Re: detect and manage power cut on MLC NAND

[Richard Weinberger]

Am 21.03.2015 um 02:48 schrieb Qi Wang 王起 (qiwang):
> For this method, my idea is we can consider page 1 and page4 as one 
> page, to program page 1 and page 4 together. So if power cut occur, 
> both page 1 and page 4 (But one page corruption in software view)will 
> corrupt at same time, won't have issue for UBI/UBIFS.

I think we could add a new mtd driver which merges paired pages into bigger
pages. We already have "funky" mtd drivers like mtd_concat. What about a mtd_unpair?
This mtd driver could also do the scrambling.

Boris, what do you think?

Thanks,
//richard

Re: detect and manage power cut on MLC NAND

[Boris Brezillon]

Hi Qi,

Sorry for the late reply (I was quite busy on other projects
lately :-/).

On Mon, 13 Apr 2015 00:44:35 +0000
Qi Wang 王起 (qiwang) <qiwang@micron.com> wrote:


> 
> Glad to meet in you ELC.

I was glad to meet you too.

> Is there any planning or idea to fix MLC power loss problem?

For the ideas part, I haven't thought about it since my talk at ELC.
I guess the solution proposed on the MTD website is a good starting
point [1].
Some guys are also considering the "avoid any erase/program operation
when you're about to loose power", but as I already explained I think
the MTD/UBI/UBIFS layers should not rely on this assumption and take
appropriate action to prevent any issue caused by unstable bits.

Best Regards,

Boris

[1]http://www.linux-mtd.infradead.org/doc/ubifs.html#L_unstable_bits

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