Message-ID: <20160612233717.23c1b91f@bbrezillon>
Date:	Sun, 12 Jun 2016 23:37:17 +0200
From:	Boris Brezillon <boris.brezillon@...e-electrons.com>
To:	"George Spelvin" <linux@...encehorizons.net>
Cc:	beanhuo@...ron.com, computersforpeace@...il.com,
	linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
	richard@....at
Subject: Re: [PATCH 2/4] mtd: nand: implement two pairing scheme

On Sun, 12 Jun 2016 23:13:14 +0200
Boris Brezillon <boris.brezillon@...e-electrons.com> wrote:

> On 12 Jun 2016 16:24:53 -0400
> "George Spelvin" <linux@...encehorizons.net> wrote:
> 
> > Boris Brezillon wrote:  
> > > On 12 Jun 2016 08:25:49 -0400
> > > "George Spelvin" <linux@...encehorizons.net> wrote:    
> > >> (In fact, an interesting
> > >> question is whether bad pages should be skipped or not!)    
> > > 
> > > There's no such thing. We have bad blocks, but when a block is bad all
> > > the pages inside this block are considered bad. If one of the page in a
> > > valid block shows uncorrectable errors, UBI/UBIFS will just refuse to
> > > attach the partition/mount the FS.    
> > 
> > Ah, okay.  I guess dealing with inconsistently-sized blocks is too much
> > hassle.  And a block has a single program/erase cycle count, so if one
> > part is close to wearing out, the rest is, too.
> > 
> > P.S. interesting NASA study of (SLC) flash disturb effects:
> > http://nepp.nasa.gov/DocUploads/9CCA546D-E7E6-4D96-880459A831EEA852/07-100%20Sheldon_JPL%20Distrub%20Testing%20in%20Flash%20Mem.pdf?q=disturb-testing-in-flash-memories  
> 
> Thanks for the link.
> 
> > 
> > One thing they noted was that manufacturers' bad-blocck testing sucked,
> > and quite a few "bad" blocks became good and stayed good over time.
> >   
> > >> Given that, very predictable writer ordering, it would make sense to
> > >> precompensate for write disturb.    
> > > 
> > > Yes, that's what I assumed, but this is not clearly documented.
> > > Actually, I discovered that while trying to solve the paired pages
> > > problem (when I was partially programming a block, it was showing
> > > uncorrectable errors sooner than the fully written ones).    
> > 
> > Were the errors in a predictable direction?  My understanding is that
> > write disturb tends to add a little extra charge to the disturbed
> > floating gates (i.e. write them more toward 0), so you'd expect
> > to see extra 1s if the chip was underprogramming in antiipation.
> > 
> > I'm also having a hard time figuring out the bit assignment.
> > In general, "1" means uncharged floating gate and "0" means charged,
> > but different sources show different encodings for MLC.
> > 
> > Some (e.g. the NASA report above) show the progression from erased to
> > programmed as
> > 
> > 11 - 10 - 01 - 00
> > 
> > so the msbit is a "big jump" and the lsbit is a "small jump", and to
> > program it in SLC mode you'd program both pages identically, then read
> > back the msbit.
> > 
> > 
> > Others, e.g.
> > http://users.ece.cmu.edu/~omutlu/pub/flash-programming-interference_iccd13.pdf
> > suggest the order is
> > 
> > 11 - 10 - 00 - 01
> > 
> > This has the advantage that a 1-level mis-read only produces a 1-bit
> > error.
> > 
> > But in this case, to get SLC programming, you program the lsbit as
> > all-ones.
> > 
> > My problem is that I don't really understand MLC programming.  
> 
> I came to the same conclusion: we really have these 2 cases in the
> wild, which makes it even more complicated to define a standard
> behavior.
> 
> > 
> >   
> > >>> [2]http://www.szyuda88.com/uploadfile/cfile/201061714220663.pdf      
> > >> 
> > >> Did you see the footnote at the bottom of p. 64 of the latter?
> > >> Does that affect your pair/group addressing scheme?
> > >> 
> > >> It seems they are grouping not just 8K pages into even/odd double-pages,
> > >> and those 16K double-pages are being addressed with stride of 3.
> > >> 
> > >> But in particular, an interrupted write is likely to corrupt both
> > >> double-pages, 32K of data!    
> > > 
> > > Yes, that's yet another problem I decided to ignore for now :).
> > > 
> > > I guess a solution would be to consider that all 4 pages are 'paired'
> > > together, but this also implies considering that the NAND is a 4-level
> > > cells, which will make us loose even more space when operating in 'SLC
> > > mode' where we only write the lower page (page attached to group 0) of
> > > each pair.    
> > 
> > It's more considering it to have 16K pages that can be accessed in half-pages.  
> 
> Yes, I know, but it's not really easy to fake that at the NAND level,
> because programming 2 pages still requires 2 page program operation.
> The MTD user could detect that the pairing scheme always exposes 2
> consecutive non-paired pages, but as you've seen, this condition does
> not necessarily imply the 'pair coupling' constraint, and we don't want
> to increase the min_io_size value if it's not really necessary.
> 
> 

I'm just realizing this is actually a non-issue for the solution we
developed with Ricard. As I said, it's unsafe to partially write a
block in MLC mode, so the only sane way is either to write a block in
SLC mode, or atomically write a block in MLC mode, and that's what
we're doing with our 'UBI LEB consolidation' approach. I'm pretty sure
the problem described in the Hynix datasheet does not happen when only
writing in SLC mode. So, even if the pairing scheme does not account
for this extra 'coupling' constraint, we should be safe.

BTW, I think I should drop the mtd_wunit_to_pairing_info() function
until someone really needs it.

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

Powered by blists - more mailing lists