public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Artem B. Bityutskiy" <dedekind@yandex.ru>
To: linux@horizon.com
Cc: kalin@thinrope.net, linux-kernel@vger.kernel.org
Subject: Re: Lifetime of flash memory
Date: Sun, 26 Mar 2006 20:36:48 +0400	[thread overview]
Message-ID: <4426C320.9010002@yandex.ru> (raw)
In-Reply-To: <20060326162100.9204.qmail@science.horizon.com>

linux@horizon.com wrote:
> Sorry, I don't have anything in particular, just bits I've picked up
> talking to CF manufacturers.
> 
> Basically, a CF card is a flash ROM array attached to a little
> microcontroller with an IDE interface.  The large manufacturers generally
> have custom controllers.
> 
I'm actually interested in:

1. CF wear-levelling algorithms: how good or bad is it?
2. How does CF implement block mapping, does it store the mapping table 
on-flash or in memory, does it build it by scanning, how scalable are 
those algorithms.
3. Does CF perform bad erasable blocks hadling transparently when new 
bad eraseblocks appear.
4. How tolerant CF to powrer-offs.
5. Is there a Garbage Collector in CF and how clever/stupid is it.

etc.

I've heard CF does not have good characteristics in the above mentioned 
aspects, but still, it would be interesting to know details. I'm not 
going to use CFs, but as I'm working with flashes, I'm just interested. 
It'd help me explaining people why it is bad to use CF for more serious 
applications then those just storing pictures.

-- 
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.

  reply	other threads:[~2006-03-26 16:36 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 [this message]
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
  -- 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=4426C320.9010002@yandex.ru \
    --to=dedekind@yandex.ru \
    --cc=kalin@thinrope.net \
    --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