From: Charles Manning <manningc2@actrix.gen.nz>
To: "Alex Lennon" <ajlennon@arcom.co.uk>
Cc: "MTD for Linux" <linux-mtd@lists.infradead.org>
Subject: Re: FW: [OT] Cf Card vs DiskOnChip -->CF wear levelling
Date: Wed, 30 Jan 2002 08:57:58 +1300 [thread overview]
Message-ID: <20020129200142.4CAF11061@creative.actrix.co.nz> (raw)
In-Reply-To: <GEEAIDAKDGCGOMMOLAHMKEONCGAA.ajlennon@arcom.co.uk>
I did read this some time back, I believe on the Sandisk www before it got
restructured (Hey, that happy looking face on their home page sure looks like
she's getting wear levelling).
I can no longer find the Sandisk reference, so I can't really support the
assertion any more. If I recall correctly, they did wear levelling on the
full-size cards but not on CF. They use (or did use) different controllers in
these cards. Here is something I found on google
http://www.technoir.nu/hplx/hplx-l/0006/msg00714.html
I guess it also comes down to your interpretation of wear levelling.
SmartMedia, for instance, does not store a count of the number of times a
block was programmed and does not do explicite wear levelling. However the
block allocation strategy will tend to provide some sort of wear levelling
(consistent with the intrinsic pool management blaah you mention below). I
hunch therefore that CF uses the same strategy.
OK so how does this translate into system reliability? Well my take on this
is as follows:
* So what? NAND is expected to fail and NAND block drivers/file systems
handle block failure. So if you wear out a block, it just gets mapped out.
THis, combined with the intrinsic blaah, is probably good enough.
* CF is far more likely to be corrupted by removing half-way through a write
or being de-powered while a write is active.
I must also apologize for saying that a FlashDrive is a wrapped up CF card. I
actually believe it is architectually similar to a full-size PCMCIA ATA card.
They look the same to the PCMCIA/IDE bus, but the full-size card provides
more space to use a better controller. This makes them more reliable.
-- CHarles
On Tue, 29 Jan 2002 07:36, Alex Lennon wrote:
> Hi Charles,
>
> >>move stuff around and level out the wearing. Some devices do not apply
>
> wear
>
> >>levelling (eg. Compact Flash and SmartMedia). Some do (eg. full-size
>
> PCMCIA
>
> >>cards, DOC, JFFS).
>
> The lack of wear-levelling on CF comes as a surprise - could you comment on
> whether the various manufacturers, such as Sandisk are making this
> assertion?
>
> The closest we have seen is in the CF Sandisk spec. where they state they
> support wear levelling - but that this '.. is an intrinsic part of the
> Erase Pooling functionality of NAND memory...', '...if necessary, CF cards
> will rewrite data from a defective sector to a good sector...'.
>
> With this type of statement it certainly doesn't appear that our flash
> lifetime calculations for a 'true' wear-levelling implementation would
> hold for CF.
>
> Best,
>
> -Alex
next prev parent reply other threads:[~2002-01-29 19:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-28 18:36 FW: [OT] Cf Card vs DiskOnChip Alex Lennon
2002-01-29 19:57 ` Charles Manning [this message]
2002-02-20 11:46 ` FW: [OT] Cf Card vs DiskOnChip -->CF wear levelling Alex Lennon
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=20020129200142.4CAF11061@creative.actrix.co.nz \
--to=manningc2@actrix.gen.nz \
--cc=ajlennon@arcom.co.uk \
--cc=linux-mtd@lists.infradead.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