From: Iwo Mergler <iwo@call-direct.com.au>
To: xiaochuan-xu <xiaochuan-xu@cqu.edu.cn>
Cc: linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: Deep thinking about the Wear-leveling mothed
Date: Thu, 31 Jul 2008 10:02:39 +1000 [thread overview]
Message-ID: <4891011F.6010306@call-direct.com.au> (raw)
In-Reply-To: <417409411.06132@cqu.edu.cn>
xiaochuan-xu wrote:
> On Wed, 2008-07-30 at 09:22 +0300, Artem Bityutskiy wrote:
>> Also, I am not sure it is save to erase one eraseblock several million
>> times and do not erase neighbor eraseblocks. There are "radiation"
>> effects in some flashes, when unused eraseblocks slowly "rot" when
>> their
>> neighbor eraseblocks are used a lot.
>
> I'm sorry but I'm not understand this clearly.
>
>
You might be aware of the fact that after erasure of NAND FLASH,
you are only allowed to write a page once (or a small number of times).
In principle, the write operation is like a logical AND between
the new page content and the old one. That is, writing '0' will
result in a '0', writing a '1' leaves the bit unchanged.
However, in this context, you must regard NAND cells as analog devices.
What you store is not numbers, but electric charge. Erasing the cells
drains the charge (='1'), writing a '0' increases the charge. A charge
above a certain threshold is read as '0', below that is read as '1'.
Due to the proximity of the NAND cells, there is some leakage between
them. Writing a '0' into a cell leaks a little charge into the neighbouring
cells. Also, writing a '1' is not quite perfect and also moves a cell
a notch towards '0'. In other words, memory contents deteriorate despite
'correct' digital operations.
The manufacturers put more effort (and silicon area) into separating
individual erase blocks than into separating individual pages than into
separating individual bits.
But nothing is perfect. Writing a page has a small effect on bits in
neighbouring pages and even in neighbouring erase blocks.
This, I think, is what Artem meant. Although it's 'leakage' rather
than 'radiation'. :-)
Kind regards,
Iwo
next prev parent reply other threads:[~2008-07-31 0:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1217327479.2812.24.camel@localhost.localdomain>
2008-07-29 10:31 ` Deep thinking about the Wear-leveling mothed xiaochuan-xu
2008-07-30 6:22 ` Artem Bityutskiy
[not found] ` <1217409842.2786.1.camel@localhost.localdomain>
2008-07-30 9:24 ` xiaochuan-xu
2008-07-31 0:02 ` Iwo Mergler [this message]
2008-07-30 10:25 ` Artem Bityutskiy
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=4891011F.6010306@call-direct.com.au \
--to=iwo@call-direct.com.au \
--cc=linux-mtd@lists.infradead.org \
--cc=xiaochuan-xu@cqu.edu.cn \
/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