HDD GURU FORUMS

Someone at Tom's Hardware was told by Kingston that their consumer grade CompactFlash cards do not incorporate wear levelling:
https://forums.tomshardware.com/threads/1-8-pata-ssd-512gb-cf-50-pin-hard-drive.3472260/

This surprised me, so I searched for clarifying information.

Flash Memory Guide (Kingston):
https://media.kingston.com/pdfs/MKF_283.1_Flash_Memory_Guide_EN.pdf

High Data Reliability: Flash memory is very reliable and many of the Flash storage device types also include Error Correction Code (ECC) checking and advanced wear leveling.

The following document makes no mention of wear levelling. Also, the term "cycles per logical sector" would imply that there is no logical-to-physical sector translation.

Kingston CompactFlash Products: CF/32, CF/64, CF/128, CF/256, CF/512, CF/1024:
http://www.wecs.de/diverse/CF_Kingston_256.pdf

capacities ranging from 32MB to 1024MB
Endurance: 300,000 cycles per logical sector

The following products refer to an obsolete "Wear Level" command (F5h). This command appears to have been used in early products that predate the Security Freeze Lock (F5h) ATA command. The implication seems to be that early CF cards performed wear levelling on demand from host based software. :-?

SanDisk Industrial Grade ATA CompactFlash, PC Card, and FlashDrive Product Manual, Version 2.6, Document No. 80-36-00208, March 2004:
https://www.as.arizona.edu/aro/adp/12meter/apex/compactFlash_IndustrialGradeATAv2.6.pdf

5.1.24. Wear Level — F5H

The Wear Level command in Table 5-31 is effectively a NOP command and only implemented for backward compatibility with earlier SanDisk SDP series products. The Sector Count Register will always be returned with a 00H indicating Wear Level is not needed.

Delkin Devices, SLC Commercial and Industrial CompactFlash CF 3.0/4.1 Standard Engineering Specification, Document Number L5ENG00049 Revision: 2.2
https://docs-emea.rs-online.com/webdocs/124c/0900766b8124cbe2.pdf

If security mode feature set is not supported, this (Security Freeze Lock - F5h) command shall be handled as Wear Level command.
...
For the CompactFlash Cards that do not support security mode feature set, this (Security Freeze Lock - F5h) command is effectively a NOP command and only implemented for backward compatibility. The Sector Count Register shall always be returned with a 00h indicating Wear Level is not needed. If the CompactFlash Card supports security mode feature set, this command shall be handled as Security Freeze Lock.

SanDisk CompactFlash Memory Card Product Manual 1998:
https://docs-emea.rs-online.com/webdocs/00af/0900766b800afe0e.pdf

1.8.4 Wear Levelling

CompactFlash Memory Card Series products do not require or perform a Wear Level operation. The command is supported as a NOP operation to maintain backward compatibility with existing software utilities.

SanDisk CompactFlash Memory Card Product Manual Rev 7, 2000:
http://static6.arrow.com/aropdfconversion/f6d67fcb0ac683ac25a8bc607c1f809097f63762/sands00003-1.pdf

6.1.23 Wear Level - F5H

This command is effectively a NOP command and only implemented for backward compatability with earlier SanDisk SDP series products. The
Sector Count Register will always be returned with an 00H indicating Wear Level is not needed.

Would "old" types of wear levelling, whitening, translation etc. that are done purely in firmware show up in these documents?

I know a lot of systems that use NAND as storage (IOT, embedded) assume you will write wear levelling, bad block management etc into your OS or driver, and no mention of it is in hardware manuals or might be minimal reference to it in data sheets

I can understand how an embedded application might leave wear levelling and bad block management up to the OS, but these CF storage devices are designed to be removable, in which case any flash metadata would need to be stored on the card. And if these old cards do support internal wear levelling, then what is the purpose of the Wear Level command? What would this command do that the drive itself would not do automatically?

fzabkar wrote:... if these old cards do support internal wear levelling, then what is the purpose of the Wear Level command? What would this command do that the drive itself would not do automatically?

Maybe the Wear Level command is intended to query the Level of Wear, ie perhaps the drive responds by reporting the average number of P/E cycles recorded to date ???

fzabkar wrote:

fzabkar wrote:... if these old cards do support internal wear levelling, then what is the purpose of the Wear Level command? What would this command do that the drive itself would not do automatically?

Maybe the Wear Level command is intended to query the Level of Wear, ie perhaps the drive responds by reporting the average number of P/E cycles recorded to date ???

Hi,
Indeed In Few Devices There is a Position in The SA Of a Page That Stores The Wear Leveling Info ,Like The Times Its Been Used In a Block ,So All Pages In Block Will Have That Same To Same

I was going to say same as Amarbir, There are bytes in some controller firmware in the SA that are for write counter for blocks or pages or both.

I also think that the term "wear levelling" gets conflated with a few actual technologies such as "Whitening" which uses XOR or encryption to raise the entropy of the data, as some patterns of bytes are not good for ensuring wear is spread. This is wear levelling, but the effect of less wear comes rather than actually having a wear levelling command.

TBH I don't know what a wear levelling command does so I should study on it.

Some people also call wear levelling the mix where a controller will alternate blocks between chips, crystals, banks, channels etc, rotate pages and other mix algorithms, but this is really so a controller can write data at the same time to different NAND areas for speed.

would be interesting to read some source code where the wear levelling ommand was used.

This datasheet for a Transcend 1GB ZIF P-ATA SSD states that the drive has "built-in 13/24 ECC (Error Correction Code) functionality and wear-leveling algorithm". It also supports the Wear Level F5h command, but does not elaborate.

Transcend TS2GSSD10-M 1.0” Solid State Disk:
https://pdf1.alldatasheet.com/datasheet-pdf/view/330232/TRANSCEND/TS2GSSD10-M.html

Doesn't fact that all (?) NAND does LBA > PBA translation imply some degree of wear leveling?

Assume we have a JPEG stored at a cluster that translates to LBA 1000 which in turn gets mapped to PBA(x). We now delete the file of which the file system is aware (at cluster level), the SD card isn't. So as far as SD Card is concerned LBA 1000 and associated PBA(x) is still in use.

Now we store a new file to LBA 1000, and since assigned PBA(x) isn't erased, it gets written and mapped to PBA(y). So file is stored in different physical location, and SD Card is now aware that PBA(x) can be discarded and is now 'stale', garbage collector at some point will take care of it.

Of course it's still possible LBA(x) pretty quickly after that, so hence this results in wear leveling only to a degree.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/466342/nand-flash-design

You will not find the wear level implementation in these source codes. These source codes are bare metal code, without operating system.
Because, usually that will be implemented in the Filesystem along with Operating system.

If you just need the code for reference, you can refer to the JFFS2 filesystem.
processors.wiki.ti.com/.../Create_a_JFFS2_Target_Image

Flash memory also have operating systems, sometimes a 80851 core

probably find a lot by going down rabbitholes such as https://www.design-reuse.com/sip/nand-flash-controller-c-367/


https://apps.dtic.mil/dtic/tr/fulltext/u2/a509258.pdf

Also, wear leveling algorithms are implemented to prohibit flash memory blocks that contain frequently-altered data from going bad more quickly than those that hold static data. There are two methods to address these requirements: a flash file system and the Flash Transition Layer (FTL). The FTL allows flash devices to be used with unmodified legacy operating systems. It introduces a logical layer above the physical layer that hides the details of flash management from the operating system. USB thumb drives and SD cards utilize an FTL. A flash file system provides better utilization of flash storage at a somewhat higher cost. Two examples of flash file systems are YAFFS, which is used in Google’s Android, and JFFS2, used in the OLPC program. The FTL and flash file system solutions both provide an opportunity to recover old data and metadata after a file is changed or deleted, and the new information is written to a new physical location.

The above is info on wear levelling specifically.

If I interpret the first post correctly, then the question is what is the deal with WL on CF cards when they apparently don't need it, or don't use it.

https://en.wikipedia.org/wiki/CompactFlash implies that CF cards came out using other memory and later used NAND... well it actually says it

CompactFlash was originally built around Intel's NOR-based flash memory, but has switched to NAND technology

if that's the case, it wasn't until NAND that WL was more integrated into the chip or controller. other earlier memory was more basic I believe... possibly more robust, lower capacity, and other factors that probably were conducive to the OS doing all the heavy lifting.

While NOR flash has higher endurance, ranging from 10,000 to 1,000,000, they haven't been adapted for memory card usage. Most mass storage usage flash are NAND based. As of 2015 NAND flash were being scaled down to 16 nm. They are usually rated for 500 to 3,000 write/erase cycles per block before hard failure