public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Lifetime of flash memory
@ 2006-03-21 17:01 John Richard Moser
  2006-03-21 17:14 ` David Vrabel
                   ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: John Richard Moser @ 2006-03-21 17:01 UTC (permalink / raw)
  To: linux-kernel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have a kind of dumb question.  I keep hearing that "USB Flash Memory"
or "Compact Flash Cards" and family have "a limited number of writes"
and will eventually wear out.  Recommendations like "DO NOT PUT A SWAP
FILE ON USB MEMORY" have come out of this.  In fact, quoting
Documentation/laptop-mode.txt:

  * If you're worried about your data, you might want to consider using
    a USB memory stick or something like that as a "working area". (Be
    aware though that flash memory can only handle a limited number of
    writes, and overuse may wear out your memory stick pretty quickly.
    Do _not_ use journalling filesystems on flash memory sticks.)

The question I have is, is this really significant?  I have heard quoted
that flash memory typically handles something like 3x10^18 writes; and
that compact flash cards, USB drives, SD cards, and family typically
have integrated control chipsets that include wear-leveling algorithms
(built-in flash like in an iPaq does not; hence jffs2).  Should we
really care that in about 95 billion years the thing will wear out
(assuming we write its entire capacity once a second)?

I call FUD.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond

    We will enslave their women, eat their children and rape their
    cattle!
                                     -- Evil alien overlord from Blasto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBRCAxdws1xW0HCTEFAQJd6w//auD2v3RJYxTbUePJwXFriCTO2d35+uo1
xU80/Brd7Hkdn82hfk/Rozoj6zsZFYYpYqqDhvo0aOKUW/cxZhTymXlEUgNXx0k+
s2hkVM4+nXoJhQhFuLk3/bPXBQlu20xA1tt6pHMscIfavijPSn7aV7gPx+L+SpDD
VqGdsmynt68IRk09b9su0gsfuM0OxYrjVAXPN5l+cjzlEk+fyHGIALu26UwiL+31
Gs86zviWaX1MwK5G0IZQ0ITySG/wNGoMNcbSdbm/45r0JnLhHPQjX2WGwIh7t5Y2
UeoYLRZJ5gRF9PT0yP5tMy0XXhKpj0aEtl8ccB/aeOCPsUKAC+2K2SFCfZLZCj8x
GOGeJKsutim+H+Qec/lnOng1LYoA9fJaisGzAUEOHYhFuYOioPVvGBKiRQlX6mMf
ofCAIOwtzWgxTa4kJrhU3oF0DYhLtP7Je/LCQW0RqmnMrXcR23/AwBa5fHTzhW1C
Mb6eL1TtYPYoyoBcKKYgKMmXLXu4d2klgxM4RRpcCrVfrupsHXr5VSzt+XYf7twX
TnY6DhmVVqp1YIVbWPXbNHplQuOU7ywdu+Y7q75jywqFBxGqeo+mPoL8ItW3IthZ
/zaoJVUH+n0FyydC+FYJ3SWx7AkPx46hZmO2UQmVlOAq2Fuc8I3haaOIQmADt0Ar
pwGzS3E92J0=
=48mD
-----END PGP SIGNATURE-----

^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: Lifetime of flash memory
@ 2006-03-23  7:49 linux
  2006-03-26 13:55 ` Artem B. Bityutskiy
  2006-03-28  0:21 ` Bill Davidsen
  0 siblings, 2 replies; 28+ messages in thread
From: linux @ 2006-03-23  7:49 UTC (permalink / raw)
  To: kalin, linux-kernel; +Cc: linux

> I thought that journaling filesystems happen to overwrite exactly the same
> place (where the journal is) many times... Am I mistaken?

Sort of.  The journal is much larger than a signle block, and used
circularly, but it does get on average more traffic than the rest of
the disk.

> So the effect is what we had for floppies (some many years ago) where sector
> 0 and others where FAT structure was kept were overused and start giving
> errors - so the only solution was to throw away that floppy.
>
> Hard disks had the same problem, but they have algorithms to relocate bad
> clusters.

Actually, hard drives shouldn't have the same problem.  The key difference
is that, on a floppy, the head touches the media, causing wear wherever
it hangs out.  The head is very smooth, so it's minor, but it happens.

On a hard drive, the head never touches the media.  There is no wear.
The magnetic writing happens across a very small air gap, and nobody's
ever found a wearout mechanism for the magnetizing part of things, so you
should be able to overwrite a single sector every rotation of the drive
(120 times a second) for the lifetime of the drive (years).

> So do these "leveling algorithms" refer to the same? Relocating bad cells?
> If not, you can see how a journaling system can fry a CF card quickly.

They do that, but they're also cleverer.  Since flash media have no
seek time, there's no reason that the sector number as specified by the
computer needs to have anything to do with the physical location of the
bits on the flash, and they don't.  If you write to the same sector over
and over, a flash memory device will do the write to different parts of
the memory chip every time.

This is called "wear leveling" - trying to use all of the chip an equal
amount.  You'll see in high-density NAND flash systems there are actually
528 bytes per "sector".  The extra 16 bytes are used to record:
- Whether this sector is still good or not
- The number of times this sector has been written
- The logical sector number of the data here

On startup, the first thing a thumb drive or CompactFlash card does is
read the extra 16 bytes from every sector and build a translation map,
so when a request for a given logical sector comes in, it knows where
to find it.  Note that there are more sectors on the ROM than on the
hard drive it emulates, so there's always some spare space.

Further, when writing, occasionally a sector that's just sitting there
not bothering anyone is copied, so that the flash it occupied can be
used by faster-changing data.

(This is all complicated by the fact that, while you can *write* one
528-byte sector at a time, you can only write to an erased sector,
and erases operate in bigger chunks, often about 8K.  Thus, it's not
physically possible to overwrite a 512-byte sector in place, even if
you wanted to!  So the controller is continuously picking an 8K chunk
to re-use, copying any live data to a new chunk, and erasing it so
it's available.  For highest speed, you want to pick chunks to recycle
that are mostly dead stale data, but for wear-leveling, you want to pick
chunks that have a low cycle count.  So you do a mix.)

See http://www.st.com/stonline/products/literature/ds/10058.htm and
the various pages and papers linked to it for more detailed info.
(Not necessarily the best-written or easiest to understand, but it's
straight from a ROM manufacturer.)


As for the average lifetime, typical specs are either 10K, 100K or 1
million writes per sector.  Basically, low-, normal- and high-endurance.
Low-endurance is used for program memory, where you might reflash it a
few times in the field, but aren't going to be using it continuously.
100K writes is the standard for data memory.

The denser the memory is, the lower the numbers tend to be.  But you
also have a bigger pool to spread the writes across.  Some folks use
multi-level cell memories, where instead of writing just 0 or 1, they add
1/3 and 2/3 values.  That fits twice as many bits in, but wears out faster
as it takes less degradation of the cell to read back the wrong value.

With perfect wear leveling, a 1 GB flash memory can thus have 100 TB
written to it before bad sectors start becoming a problem.  (And if you
allowed more spare sectors to start with, you would have more time.
One reason to integrate this into the file system and not emulate a
fixed-size disk.)

Assuming 10 MB/sec write speed (typical for a USB thumb drive) that
would require 10^7 seconds (115 days) of continuous full-speed writing.

So yes, a thumb drive isn't the best choice for on-line transaction
processing.  But with less than 24x7 usage, it'll last many years.


Note that, assuming a decent wear-leveling algorithm (admittedly, a big
IF for some of the cheaper stuff out there!) it doesn't matter which
sectors you write that 100 TB to.  It could be all the boot sector,
or sequential overwrites of the whole drive.

^ permalink raw reply	[flat|nested] 28+ messages in thread
end of thread, other threads:[~2006-03-30 12:18 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-21 17:01 Lifetime of flash memory 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
  -- strict thread matches above, loose matches on Subject: below --
2006-03-23  7:49 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
2006-03-28  0:21 ` Bill Davidsen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox