public inbox for linux-mmc@vger.kernel.org
 help / color / mirror / Atom feed
From: "Richard A. Smith" <richard@laptop.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "C. Scott Ananian" <cscott@laptop.org>,
	Kevin Gordon <kgordon420@gmail.com>,
	devel@lists.laptop.org, linux-mmc@vger.kernel.org
Subject: Re: Memory replacement
Date: Sun, 13 Mar 2011 17:31:46 -0400	[thread overview]
Message-ID: <4D7D37C2.2030102@laptop.org> (raw)
In-Reply-To: <201103131821.00762.arnd@arndb.de>

On 03/13/2011 01:21 PM, Arnd Bergmann wrote:

>>> Do you have test results somewhere publically available? We are currently
>>> discussing adding some tweaks to the linux mmc drivers to detect cards
>>> with certain features, and to do some optimizations in the block layer
>>> for common ones.
>>
>> http://wiki.laptop.org/go/NAND_Testing
>
> Ok, so the "testing" essentially means you create an ext2/3/4 file system
> and run tests on the file system until the card wears out, right?

The qualifying test is that the card must pass 3TB of writes with no 
errors.  We run that on samples from the various mfg's.

There's a 2nd round of test(s) that runs during the manufacturing and 
burn-in phases. One is a simple firmware test to see if you can talk the 
card at all and then one runs at burn in.  It doesn't have a minimum 
write size criteria but during the run there must not be any bit errors.

> It does seem a bit crude, because many cards are not really suitable
> for this kind of file system when their wear leveling is purely optimized
> to the accesses defined in the sd card file system specification.
>
> If you did this on e.g. a typical Kingston card, it can have a write
> amplification 100 times higher than normal (FAT32, nilfs2, ...), so
> it gets painfully slow and wears out very quickly.

Crude as they are they have been useful tests for us.  Our top criteria 
is reliability.  We want to ship the machines with a SD card thats going 
to last for the 5 year design life using the filesystem we ship.  We 
tried to create an access pattern was the worst possible and the highest 
stress on the wear leveling system.

If a card pases the 3TB abuse test then we are pretty certain its going 
to meet that goal.  There were many cards that died very quickly.

The tests have also helped expose other issues with things like sudden 
power off.  In one case a SPO during a write would corrupt the card so 
badly it became useless.  You could only recover them via a super secret 
tool from the manufacturer.

> I had hoped that someone already correlated the GC algorithms with
> the requirements of specific file systems to allow a more systematic
> approach.

At the time we started doing this testing none of the log structure 
filesystems were deemed to be mature enough for us to ship. So we didn't 
bother to try and torture test using them.

If more precision tests were created that still allowed us to make a 
reasonable estimate of data write lifetime we would be happy to start 
using them.

-- 
Richard A. Smith  <richard@laptop.org>
One Laptop per Child

  reply	other threads:[~2011-03-13 21:31 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 [this message]
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
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=4D7D37C2.2030102@laptop.org \
    --to=richard@laptop.org \
    --cc=arnd@arndb.de \
    --cc=cscott@laptop.org \
    --cc=devel@lists.laptop.org \
    --cc=kgordon420@gmail.com \
    --cc=linux-mmc@vger.kernel.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