Assuming we can solve the physical access problems to NAND and NOR devices for recovery (that is with a controller failure), as my previous post mentioned, the next challenge is resolving the block mapping.

Block mapping is essential to prolong the life of FLASH where the cells can fail after a few 100k write cycles. Imagine a hefty telecom call data record, or temporary database with millions of 1k files; contiually being processed. [Admittedly you'd be better off with DRAM based solid state disk for that...] a few 100k writes to the same block would undoutedly happen within a week and CAPUT!

Write levelling or staggering implemented as an alogrithm will stagger writes across the drive.

We're doing some testing to try and predict the write levelling methodology, but it takes time!

sceggs

Hi Sceggy,

What you say is correct, but we should need the datasheets of the controller used in the flash device.
Then we can see what algoritm is used.
However, these datasheets are difficult to get.
Do you know a good source ?

Best regards,

Dobre

If you look at the EPROM/NAND flash programmer sites, they often have a database of links or even the database sheets themselves.

Companies such as Advin, Xeltek to name a few (plus others).

scegs

These are the datasheets of the memories themselves, but not of the controller that handles the access to the memories.

Or am i mistaken ?

Regards,

Dobre

Over the lifetime of NAND, flash management has migrated from the host to the device itself...making it more interesting from recovery perspective.

---
The latest NAND based device that we have had in our lab today has a bespoke ARM microcontroller as a component of the ASIC/FPGA which includes the host interface circuitry. These will have different revisions of firmware depending on the laser etching, and/or the serial no tag on the actual FLASH device. Most manufacturers have a translation table between the part number and chipset and firmware.

So we're almost at the same stage as with hard disks - getting the right firmware modules.

Write Levelling / Wear Level / is more pronounced on more expensive NAND devices (less so on MP3 players/cameras. CRC checking ensures the virtual block mapping will spread writes across cells/blocks.

In some NAND Flash IDE drives there is a WEAR LEVEL Command Register (F5h) which uses Head Select and Features Register (ATA).

---
On Flash Memory Controllers (do a google search USB Flash Memory Controller)....the wear level management will probably be stored in ROM along with the NAND programming algorithm.

However the vectors that hold the wear levelling (which will be different from device to device, even of the same product) must be stored in non-volatile memory - i.e. flash itself.

In our research we have found the following algorithms in use:

BASIC Free blocks that have had fewest write cycles using
(1) Chain Method - all free physical blocks held in a pool. Chain of physical blocks are assigned to every virtual block; and every time a virtual block needs to be allocated, a physical block is selected from the chain. Mostly round-robin (as per RAID read)...

(2) Array Method - measures program/erase cycles by block, and this information or vector is loaded into RAM

ADVANCED Long lived data is held in older blocks. Basically the algorithm ensues that the average wear on each block is the same.

--

In addition to wear levelling, you also need to manage the bad-blocks that appear in the device and grow over time...

--

You may want to look at Intel's Virtual Small Block technology for additional ideas...

---
And another point... a number of US and other patents have been granted in this paticular area. Lookup assignees=Storage Technology Corporation, for example 10672786...

physical block<->virtual block addressing is often held in the physical block.

scegy

How can wear-levelling even be implemented on a flash memory card that leaves the filesystem encoding up to the device accessing it? Wouldn't it have to impose a particular filesystem (FAT16, for example) and virtualize it, and totally screw up if formatted with a different filesystem? Otherwise, how could it possibly "know" which sectors are in use and which are free? If I delete files on a flash card, the data is still there and accessable; only the pointers are deleted. How can this fact possibly coexist with wear-levelling?

Qubit,


Every flash memory card has a controller which handles the requests from the PC, and translates them to the correct sectors.
So it is independent from the filesystem.

Regards,

Dobre

_________________
Murphy was an optimist

Datarecovery in Belgium, Holland, France and Germany
Datarecoverytools http://www.drtools.eu

Dobre,

Yes, a flash card's controller handles the mapping of software sectors to hardware sectors. However, it could easily do a static mapping, where the same software sector always maps to the same hardware sector. What I don't understand is how it could possibly do a variable mapping, which would be necessary for write levelling. The whole idea of write levelling is that if you write to the same sector multiple times, the actual writes are mapped to different hardware sectors so that the same sector doesn't get "worn out", right? But, how could variable mapping possibly be done if the flash card has no control over the filesystem? The controller would have no way of knowing which sectors were free to be remapped.

David

Hi,

This is mostly true, however for example SmartMedia cards do not have any controller, they are a pretty faced NAND flash memory chip like one in a CF card.

pepe

_________________
Adatmentés - Data recovery

Do any flash media cards (SmartMedia, CompactFlash, xD, SD, Memory Stick) actually use write levelling at all?

I can't see how the answer could be anything other than "no", but maybe I'm missing something.

Hi Qubit,

I cannot answer that question, unfortunately, since i cannot find any datasheets about the controllers.
I wrote to the manufacturers, but i guess they are not interested if they cannot sell

So, honestly, i dont know.

Dobre

_________________
Murphy was an optimist

Datarecovery in Belgium, Holland, France and Germany
Datarecoverytools http://www.drtools.eu

Hi,

of course they do!
that's why the data is scattered and not continuous most of the cases.

pepe

_________________
Adatmentés - Data recovery