public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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

  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