From: Mark Rustad <mrustad@mac.com>
To: lsorense@csclub.uwaterloo.ca (Lennart Sorensen)
Cc: linux-kernel@vger.kernel.org, "Michael H. Warfield" <mhw@wittsend.com>
Subject: Re: Flash device types
Date: Fri, 13 May 2005 13:52:37 -0500 [thread overview]
Message-ID: <c34f1e127a3bd4cbf62a0b81350ab6e8@mac.com> (raw)
In-Reply-To: <20050513182650.GJ23488@csclub.uwaterloo.ca>
On May 13, 2005, at 1:26 PM, Lennart Sorensen wrote:
> Not really. I believe sandisk has wear leveling on the 201 series CF
> cards and on their new generation CF/SD for sure they have it (and
> unfortunately for us they discontinued industrial temperature in the
> new
> line so we have had to look elsewhere for CF cards).
>
> Unfortunately a lot of what is sold to consumers at retail is cheap
> crap. :)
It does seem to be a problem finding out how things really work in
these devices. There seem to be the following types (from worst to
best):
1. No wear leveling. Bad blocks are mapped out at manuf. time and that
is it.
2. Bad blocks are detected and remapped dynamically. This is sometimes
called wear-leveling, but the device life is a function of how many
spares there originally were.
3. "Real" wear leveling. This can move data to fully use the life of
all sectors.
4. "Real" wear leveling with lots of optimization and write cache -
these are large devices usually with the ability to have battery power
to ensure write cache can be flushed out.
#4 is easy to determine because of the size and complexity of the
things. The others are much harder to distinguish and it really is
important to know what you are dealing with. If you can't find out how
it works, I would assume #1 or #2 which are both pretty poor.
It really would be nice to easily find out what category of device
these things really are.
--
Mark Rustad, MRustad@mac.com
next prev parent reply other threads:[~2005-05-13 18:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-13 16:20 Sync option destroys flash! Michael H. Warfield
2005-05-13 17:17 ` Lennart Sorensen
2005-05-13 17:53 ` Michael H. Warfield
2005-05-13 18:09 ` Lennart Sorensen
2005-05-13 18:21 ` Michael H. Warfield
2005-05-13 18:26 ` Lennart Sorensen
2005-05-13 18:52 ` Mark Rustad [this message]
2005-05-13 18:53 ` Michael H. Warfield
2005-05-13 17:58 ` Zan Lynx
2005-05-13 18:13 ` Lennart Sorensen
2005-05-13 18:40 ` Alan Cox
2005-05-13 19:10 ` Michael H. Warfield
2005-05-13 22:00 ` Alan Cox
2005-05-13 22:22 ` Måns Rullgård
2005-05-13 23:24 ` Jon Masters
2005-05-13 23:01 ` Jeffrey Hundstad
2005-05-13 23:27 ` Jon Masters
2005-05-14 10:17 ` Jörn Engel
2005-05-14 1:05 ` Michael H. Warfield
2005-05-17 13:30 ` Lennart Sorensen
2005-05-13 21:25 ` Lee Revell
2005-05-13 22:43 ` Alan Cox
2005-05-15 19:00 ` Denis Vlasenko
2005-05-16 0:23 ` Mark Lord
2005-05-16 9:29 ` David Woodhouse
2005-05-16 16:42 ` Pavel Machek
2005-05-16 13:01 ` Richard B. Johnson
2005-05-16 23:18 ` Helge Hafting
2005-05-18 7:03 ` Denis Vlasenko
2005-05-17 7:59 ` Colin Leroy
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=c34f1e127a3bd4cbf62a0b81350ab6e8@mac.com \
--to=mrustad@mac.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lsorense@csclub.uwaterloo.ca \
--cc=mhw@wittsend.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
all inboxes | Powered by JetHome®