Olympus-OM
[Top] [All Lists]

Re: [OM] SD Stuff

Subject: Re: [OM] SD Stuff
From: philippe.amard@xxxxxx
Date: Sat, 23 Mar 2013 19:12:45 +0100 (CET)
So complex!


As a user it all boils down to which is more convenient to me, and where are 
the risks more limited to lose content?


I own and use about 12 SD cards, from 2 to 32 Mp, none of which has failed over 
a 7 years's period.
None of the 4 xD we have has ever caused any concern.
I also use 8 CFs, all 8Mp, 2 of which have failed so far, the 2 Kodak I had 
bought in emergency in Lituania...
Sandisk rescue sofware did wonders on those 2, but one is definitely out of 
order for recording so on a trip, I'll use the other one only as a matter of 
desperate last resort when all the other cards are full to the brim.


OTT, I always reformat the cards in camera after LR automatic download using a 
card reader.


Amitiés
Philippe, a user friendliness addict since the invention of the computer ...


========================================

Message du : 23/03/2013 18:56
De : "Ian Manners " <void@xxxxxxxxxx>
A : "Olympus Camera Discussion" <olympus@xxxxxxxxxxxxxxxxx>
Copie à : 
Sujet : [OM] SD Stuff


 Hi Chuck,

You will have to forgive me, I'm trying to keep it simple,
and thats not always easy to do while keeping a reply short
especially when I'm tired.

Current SDD Drives do remap all faulty memory
address's irrespective of there location, including faulty
memory in the block allocation tables so that the device
its connect to has no idea.

As far as I'm aware the SD Card standard doesnt do this
yet but I could be wrong on that, I havent kept up to
date with it so if you say it does do it now I'll take
your word on it.

Bad block management is a relatively new feature in
NOR chips

> Dunno where you heard this.  Sounds like web lore to me.
>  From the Wiki article on flash memory
> 

Thought we were talking about SD cards, yes its all
NAND 
but much depends on the controller and which parts
of the SD standards are implemented.

Up until SDHD/XC/IO the onboard controller was very
basic, as far as I'm aware it only included the Serial
Peripheral Interface (SPI), the SD Bus modes, and DRM
functions (which was why it was called Secure Digital).
The rest was left to the device that it was connecting to.



SD Cards site between the xD card (no controller onboard),
and CF Cards (full controller on board).

The early SD card controllers didn't do wear leveling,
then they did wear leveling only for the data areas and
storing the required mapping at the start of the card
memory area.

Also keep in mind that the area were the Bad Block Map
is stored is the weak link. If a bad bit resides in this area
many controllers (on the device using the card) couldn't
remap the Bad Block Map, this area also includes the
file allocation table.

If you use a card with a problem in the FAT/Map area,
this is why you can often read it and fix it on a computer,
it's also part of the reason you can often read and view the
files on a good camera but have corruption issues on another
camera or non computer device (like a printer with an SD slot)
much depends on the controller.

Ignoring the fact the some of the cheaper cameras from
China were using unlicensed SD forms which did not
have all the correct implementions of the 'standard'.

> NAND devices also require bad block management by the device driver 
> software, or by a separate controller chip. SD cards, for example, 
> include controller circuitry to perform bad block management and wear 
> leveling. When a logical block is accessed by high-level software, it is 
> mapped to a physical block by the device driver or controller. A number 
> of blocks on the flash chip may be set aside for storing mapping tables 
> to deal with bad blocks, or the system may simply check each block at 
> power-up to create a bad block map in RAM. The overall memory capacity 
> gradually shrinks as more blocks are marked as bad.

What you say above is correct for the current SDHD cards
as far as I'm aware, with the new smarts in SDXC and SDIO,
prior to that they relied on a bad block map as part of the file
structure. This is one of the reason's so many problems were
occuring and I can only assume this, that Olympus and others
didnt use SD cards (on top of the royalties they have to pay
to use this format).

> NAND relies on ECC to compensate for bits that may spontaneously fail 
> during normal device operation. A typical ECC will correct a one-bit 
> error in each 2048 bits (256 bytes) using 22 bits of ECC code, or a 
> one-bit error in each 4096 bits (512 bytes) using 24 bits of ECC 
> code.[22] If the ECC cannot correct the error during read, it may still 
> detect the error. When doing erase or program operations, the device can 
> detect blocks that fail to program or erase and mark them bad. The data 
> is then written to a different, good block, and the bad block map is 
> updated.

The quality (differing) of what is in a SD card is well known,
just as the differing quality of USB sticks.

> Dr. (wear leveled and bad block managed) Flash

Even the early SDD Drives didnt do wear leveling at
all, it was left to people to write that into device drivers
after the fact, now its all transparent on the controller.

I'm sure that wasnt that many years ago, was it ?

This caused absolute havok with operating systems that
couldnt run the SDD providers manual wear leveling
utilities back in the day. Like OS/2 and Linux.

Cheers
Ian Manners
Of nowhere in particular.
-- 
_________________________________________________________________
Options: http://lists.thomasclausen.net/mailman/listinfo/olympus
Archives: http://lists.thomasclausen.net/mailman/private/olympus/
Themed Olympus Photo Exhibition: http://www.tope.nl/

-- 
_________________________________________________________________
Options: http://lists.thomasclausen.net/mailman/listinfo/olympus
Archives: http://lists.thomasclausen.net/mailman/private/olympus/
Themed Olympus Photo Exhibition: http://www.tope.nl/

<Prev in Thread] Current Thread [Next in Thread>
Sponsored by Tako
Impressum | Datenschutz