Messages in this thread | | | Date | Tue, 14 Jun 2016 11:34:26 +0200 | From | Boris Brezillon <> | Subject | Re: [PATCH 2/4] mtd: nand: implement two pairing scheme |
| |
On 14 Jun 2016 05:07:26 -0400 "George Spelvin" <linux@sciencehorizons.net> wrote:
> Boris Brezillon wrote: > > On 12 Jun 2016 16:24:53 George Spelvin wrote: > >> Boris Brezillon wrote: > >> 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. > > I did find a useful stuy of the issue: "Program Interference in MLC NAND > Flash Memory: Characterization, Modeling, and Mitigation" > > https://users.ece.cmu.edu/~omutlu/pub/flash-programming-interference_iccd13.pdf > > It describes the write-disturb-precompensation technique, and also > shows how the two-stage programming works. (Although the fact that the > "least significant bit" is the *largest* voltage difference and is shown > on the *left* makes no sense at all.) > > Looking at the demonstrated programming sequence, it looks like > it should be possible to probe for the bit assignment. If you have > a half-programmed page, then any bits programmed to "0" are actually > sitting close to the threshold between the two middle voltage levels. > > So you'll get a lot of errors reading them as "1", but the interesting > part is the read-back of the unprogrammed bit. > > If the chip is using the binary sequence, you'll read either 10 or 01. > If the chip us ising the Gray-code sequence, you'll read 10 or 00. > > Basically, you read both pages and see which bit combination never > appears. That is the combination that corresponds to the highest voltage > level. > > Another interesting paper is "Read Disturb Errors in MLC NAND Flash > Memory: Characterization, Mitigation, and Recovery" > https://users.ece.cmu.edu/~omutlu/pub/flash-read-disturb-errors_dsn15.pdf > > That talks about tricks that do as you observe: increase read error to start. > (In order to decreaease read disturb, and thus read errors later.)
Thanks a lot for sharing your thoughts along with all these references, that's really useful. I'll carefully read all of them.
> > >> 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. > > Ideally, it would be nice to separate the "SLC hack" from the "later > write failures can corrupt earlier data" workaround. > > First, you get the latter working on SLC flash.
When you say SLC flash, you're talking about MLC NANDs operating in SLC mode, right?
> Then you add MLC, and > make MLC another reason why it can happen. > > But I'm not certain this is actually necessary. Could listing 4 pages > rather than 2 as in other data sheets just be an editing or translation > error? Maybe someoe got confused about "in the same row" when they > wrote that clarifying example.
Yes, that's what I supposed. I'll try to test that on a real device.
> > > 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. > > I can't see any reason why it would affect MLC and not SLC.
That's something we'll have to check on a real NAND exposing this constraint (I'll try to find a board with one of these NANDs), but if that's really the case, and programming page 1 can really spoil page 0 even if they're not sharing the same cells, then that's a big problem.
-- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
| |