public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sergei Organov <osv@javad.com>
To: linux@horizon.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Lifetime of flash memory
Date: Thu, 30 Mar 2006 16:18:40 +0400	[thread overview]
Message-ID: <87r74k3z33.fsf@javad.com> (raw)
In-Reply-To: <20060330112349.11324.qmail@science.horizon.com> (linux@horizon.com's message of "30 Mar 2006 06:23:49 -0500")

linux@horizon.com writes:

>>>>> Due to the multiplexing scheme used in high-density NAND flash devices,
>>>>> even the non-programmed cells are exposed to a fraction of the programming
>>>>> voltage and there are very low limits on the number of write cycles to
>>>>> a page before it has to be erased again.  Exceeding that can cause some
>>>>> unwanted bits to change from 1 to 0.  Typically, however, it is enough
>>>>> to write each 512-byte portion of a page independently.
>>>>
>>>> Well, I'm not sure. The Toshiba and Samsung NANDs I've read manuals for
>>>> seem to limit number of writes to a single page before block erase, --
>>>> is 512-byte portion some implementation detail I'm not aware of?
>>>
>>> No.  I just meant that I generally see "you may program each 2K page a
>>> maximum of 4 times before performing an erase cycle", and I assume the
>>> spec came from 2048/512 = 4, so you can program each 512-byte sector
>>> separately.
>>
>> I've a file system implementation that writes up to 3 times to the first
>> 3 bytes of the first page of a block (clearing more and more bits every
>> time), and it seems to work in practice, so maybe this number (4) came
>> from another source? Alternatively, it works by accident and then I need
>> to reconsider the design.
>
> No, I'm sorry, I was still unclear.  The spec is 4 writes per page.
> I believe that the REASON for this spec was so that people could write
> 512+16 bytes at a time just like they did with small-block devices and
> it would work.

Ah, now (due to your explanation below) I see! But then how do you
explain that those old "small page" devices do support multiple writes
to a single page?

> But I do not believe there is any limitation on the pattern you may use,
> so your system should work fine.
>
> What confuses me is that I thought I said (quoted above; paraphrasing
> here) "there is a very low limit on the number of times you may write
> to a page.  That limit is large enough that you can do pagesize/512 =
> 2048/512 = 4 separate 512-byte writes."  I didn't intend to imply that
> that was the ONLY legal pattern.
>
> But from your comments, I'm getting the impression that you think I did
> say that was the only legal pattern.  If that impression is correct,
> I'm not sure how you read that into my statements.

Well, after your last explanation I'm not sure myself how I've read that
into your statements ;)

> (I wonder if the actual limit is the number of writes per BLOCK, and
> they just expressed it as writes per page.  I don't know enough about
> the programming circuitry to know what's exposed to what voltages.
> If the physics implied it, it would be useful flexibility for file system
> design.)

I doubt block is relevant here, otherwise there seems to be no reason to
introduce "page" as a write unit in the first place. It seems that write
voltage is applied to entire page, and bit 1 in the data indeed leaks
some charge (less than 1/4 of those bit 0 leaks). I think block in this
context is mentioned only because it's impossible to erase single page.

-- Sergei.

  reply	other threads:[~2006-03-30 12:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-23  7:49 Lifetime of flash memory linux
2006-03-26 13:55 ` Artem B. Bityutskiy
2006-03-26 16:21   ` linux
2006-03-26 16:36     ` Artem B. Bityutskiy
2006-03-27 16:18       ` Lennart Sorensen
2006-03-27 17:44         ` linux-os (Dick Johnson)
2006-03-27 18:01           ` Lennart Sorensen
2006-03-28  4:28           ` Sergei Organov
2006-03-28  6:41             ` Magnus Damm
2006-03-28  8:58               ` Sergei Organov
2006-03-28 12:55             ` linux-os (Dick Johnson)
2006-03-28 13:27               ` Sergei Organov
2006-03-28 13:35               ` Sergei Organov
2006-03-29  1:01             ` linux
2006-03-29  4:33               ` Sergei Organov
2006-03-29 15:56                 ` linux
2006-03-30  6:33                   ` Sergei Organov
2006-03-30 11:23                     ` linux
2006-03-30 12:18                       ` Sergei Organov [this message]
2006-03-28  0:21 ` Bill Davidsen
  -- strict thread matches above, loose matches on Subject: below --
2006-03-21 17:01 John Richard Moser
2006-03-21 17:14 ` David Vrabel
2006-03-21 17:28   ` John Richard Moser
2006-03-21 18:37     ` Paulo Marques
2006-03-21 18:00   ` hackmiester / Hunter Fuller
2006-03-21 18:20 ` Joshua Kugler
2006-03-21 18:40   ` John Richard Moser
2006-03-23  3:46 ` Kalin KOZHUHAROV

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=87r74k3z33.fsf@javad.com \
    --to=osv@javad.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    /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