From: Arnd Bergmann <arnd@arndb.de>
To: John Watlington <wad@laptop.org>
Cc: mikus@bga.com, "Richard A. Smith" <richard@laptop.org>,
devel@lists.laptop.org, linux-mmc@vger.kernel.org
Subject: Re: Memory replacement
Date: Mon, 14 Mar 2011 20:18:29 +0100 [thread overview]
Message-ID: <201103142018.29705.arnd@arndb.de> (raw)
In-Reply-To: <CB98789C-76FD-4C0E-B7CA-FB41A3F32757@laptop.org>
On Monday 14 March 2011 19:50:27 John Watlington wrote:
> Cards that are in the state you describe are most likely dead due to
> running out of spare blocks. There is nothing that can be done to
> rehabilitate them, even using the manufacturer's secret code.
> In a disturbing trend, most of the cards I've returned for failure analysis
> in the past year have been worn out (and not just trashed meta-data
> due to a firmware error).
Part of the explanation for this could be the fact that erase block
sizes have rapidly increased. AFAIK, the original XO builtin flash
had 128KB erase blocks, which is also a common size for 1GB SD and
CF cards.
Cards made in 2010 or later typically have erase blocks of 2 MB, and
combine two of them into an allocation unit of 4 MB. This means that
in the worst case (random access over the whole medium), the write
amplification has increased by a factor of 32.
Another effect is that the page size has increased by a factor of 8,
from 2 or 4 KB to 16 or 32 KB. Writing data that as smaller than
a page is more likely to get you into the worst case mentioned
above. This is part of why FAT32 with 32 KB clusters still works
reasonably well, but ext3 with 4 KB blocks has regressed so much.
Arnd
next prev parent reply other threads:[~2011-03-14 19:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <AANLkTikQOVa8qfU-R6uqQXKhAVxqeAmxKONjPmmqLCr8@mail.gmail.com>
[not found] ` <201103111135.01394.arnd@arndb.de>
[not found] ` <320717C0-7117-462E-9227-7966EE6941D7@laptop.org>
2011-03-12 22:51 ` Memory replacement Arnd Bergmann
2011-03-13 1:01 ` C. Scott Ananian
2011-03-13 12:57 ` Andrei Warkentin
2011-03-13 17:00 ` C. Scott Ananian
2011-03-13 17:06 ` C. Scott Ananian
2011-03-13 17:21 ` Arnd Bergmann
2011-03-13 21:31 ` Richard A. Smith
2011-03-13 22:34 ` Mikus Grinbergs
2011-03-14 14:01 ` Arnd Bergmann
2011-03-14 14:17 ` Richard A. Smith
2011-03-14 18:50 ` John Watlington
2011-03-14 19:18 ` Arnd Bergmann [this message]
2011-03-15 0:29 ` John Watlington
2011-03-15 8:42 ` Arnd Bergmann
2011-03-14 17:32 ` Arnd Bergmann
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=201103142018.29705.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=devel@lists.laptop.org \
--cc=linux-mmc@vger.kernel.org \
--cc=mikus@bga.com \
--cc=richard@laptop.org \
--cc=wad@laptop.org \
/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