From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: "George Spelvin" <linux@sciencehorizons.net>
Cc: beanhuo@micron.com, computersforpeace@gmail.com,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
richard@nod.at
Subject: Re: [PATCH 2/4] mtd: nand: implement two pairing scheme
Date: Sun, 12 Jun 2016 23:13:14 +0200 [thread overview]
Message-ID: <20160612231314.15d06854@bbrezillon> (raw)
In-Reply-To: <20160612202453.21265.qmail@ns.sciencehorizons.net>
On 12 Jun 2016 16:24:53 -0400
"George Spelvin" <linux@sciencehorizons.net> wrote:
> Boris Brezillon wrote:
> > On 12 Jun 2016 08:25:49 -0400
> > "George Spelvin" <linux@sciencehorizons.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.
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-06-12 21:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-11 22:30 [PATCH 2/4] mtd: nand: implement two pairing scheme George Spelvin
2016-06-12 7:20 ` Boris Brezillon
2016-06-12 9:23 ` George Spelvin
2016-06-12 11:11 ` Boris Brezillon
2016-06-12 12:25 ` George Spelvin
2016-06-12 12:42 ` Boris Brezillon
2016-06-12 15:10 ` Boris Brezillon
2016-06-12 20:24 ` George Spelvin
2016-06-12 21:13 ` Boris Brezillon [this message]
2016-06-12 21:37 ` Boris Brezillon
2016-06-14 9:07 ` George Spelvin
2016-06-14 9:34 ` Boris Brezillon
2016-06-14 20:29 ` Boris Brezillon
-- strict thread matches above, loose matches on Subject: below --
2016-04-25 10:01 [PATCH 0/4] mtd: add support for pairing scheme description Boris Brezillon
2016-04-25 10:01 ` [PATCH 2/4] mtd: nand: implement two pairing scheme Boris Brezillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160612231314.15d06854@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=beanhuo@micron.com \
--cc=computersforpeace@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux@sciencehorizons.net \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox