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: Tue, 15 Mar 2011 09:42:04 +0100 [thread overview]
Message-ID: <201103150942.04690.arnd@arndb.de> (raw)
In-Reply-To: <CB07FC9E-B64C-4B59-98F7-CD1F6FFFBA7B@laptop.org>
On Tuesday 15 March 2011 01:29:19 John Watlington wrote:
> On Mar 14, 2011, at 3:18 PM, Arnd Bergmann wrote:
>
> > 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.
>
> The explanation is simple: manufacturers moved to two-bit/cell (MLC) NAND Flash
> over a year ago, and six months ago moved to three-bit/cell (TLC) NAND Flash.
> Reliability went down, then went through the floor (I cannot recommend TLC for
> anything but write-once devices). You might have noticed this as an increase in
> the size of the erase block, as it doubled or more with the change.
That, and the move to smaller structures (down to 25 nm) has of course
reduced reliablility further, down to 2000 or so erase cycles per block,
but that effect is unrelated to the file system being used.
My point was that even if the card was done perfectly for FAT32 (maybe a
write amplification of 2), the changes I described are pessimising ext3
(data from my head, easily off by an order of magnitude):
drive block page erase w-amplftn expected life
size size size cycles FAT ext3 FAT ext3
2005 SLC 256 MB 64 KB 1 KB 100000 2 8 13 TB 3.2 TB
2005 MLC 512 MB 128 KB 2 KB 10000 2 16 2.5 TB 640 GB
2011 SLC 4 GB 2 MB 8 KB 50000 2 512 100 TB 200 GB
2011 MLC 8 GB 4 MB 16 KB 5000 2 1024 20 TB 40 GB
2011 TLC 16 GB 4 MB 16 KB 2000 2 1024 16 TB 32 GB
The manufacturers have probably mitigated this slightly by using more
spare blocks, better ECC and better GC over the years, but essentially
your measurements are matching the theory.
Arnd
next prev parent reply other threads:[~2011-03-15 8:42 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
2011-03-15 0:29 ` John Watlington
2011-03-15 8:42 ` Arnd Bergmann [this message]
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=201103150942.04690.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