Corrupted SD Card

They do that only because of the "principle of least surprise", i.e. this way they can test the card without overwriting everything already on it, and destroying the filesystem.

Also, this way they can do it as a normal user, not an administrator that has low-level access to the block level.

Of course, it reduces the quality of the test. But it quickly reveals fraudulous cards, which is what its primary purpose is.

Yes, but on the SDcard there is yet another controller that translates the SDcard block read/writes into flash memory read/writes, and the USB reader has no knowledge about which particular flash memory location is being written when it writes to block #n.

Only the externally visible space. After filling up the card completely, there still are memory blocks available on the card that will be used when other blocks go bad or as part of the wear-leveling, and when those blocks return corrupted data h2test is never going to notice it on your first run. It may notice it when you re-run it after you have found that the card is bad by other means.

And the controller in the card is custom and wear-leveling etc. is never specified. It's not part of the SD spec. I'm sure if you go back to original cards of say 32/64Mb they did no leveling at all.

I'm probably just going to send it back to Amazon.

---druck

Yes, interesting - as you say, there's no mention of wear levelling in association's Physical Layer or Host Controller Simplified Specs and as all the other specs deal with SD card interfacing, it would be odd find anything about wear leveling there. FWIW the main Wikipedia article implies that they all have wear levelling but that the official spec doesn't say how it is to be implemented. That would seem to be right, since its hard to see how an SD card with FAT formatting could last long without wearing out the main control blocks.

I think that is not so remarkable, after all it is not specified for USB sticks as well. And comparable details like encoding or FEC on harddisks is not specified in SATA or IDE either. The device acts as a more or less reliable store for data addressed by block number, and how that is implemented is not of interest in the specification of the interface. As a result, it was possible to build flash disks with SATA interface and it would probably be possible to build a tiny harddisk with SD interface. (they have been built for CF interface, a slightly larger form factor developed for flash cards)

Are pi cards formatted with FAT? Or EXT4?

-- The biggest threat to humanity comes from socialism, which has utterly diverted our attention away from what really matters to our existential survival, to indulging in navel gazing and faux moral investigations into what the world ought to be, whilst we fail utterly to deal with what it actually is.

Both.

visible

time?

larger

And presumably when usable physical blocks becomes

Possibly. I skimmed the specs and Wiki article[*] looking for anything about wear levelling ans EOL, but didn't notice anything about what happens if/when a card runs out of usable physical blocks. Maybe you're meant to have lost or broken on it by then.

• somewhat surprisingly those were the only two technical SD Card items turned up by a web search. The rest were ads for SD cards and advice on which types to choose for various tasks.

Fair comment.

That's one's a no-brainer: the CF interface is pin-for-pin compatible with the old 40 pin IDE floppy interface.

I have an adapter card that lets a CF-card replace a 3.5" or 5.25" floppy drive which I've never quite gotten round to using.

Well that's what my Samsung Evo branded Class 10 16GB did, but others including non Evo branded Samsung 8GB haven't. So I wouldn't rely on that behaviour to tell you the card is at end of life. Others may start showing filing system errors, crashes, or just die completely without warning.

---druck

Correction: 40 pin *HDD* IDE interface.

This is the behaviour you expect from an Enterprise class SSD, although it varies by manufacturer. (End of life for Enterprise SSDs is defined as the point where they can no longer guarantee to retain data for 3 months powered off.) Another behaviour (Intel IIRC) is to reduce the write throughout to an extremely low level - typically just enough to be able to mount filesystems so data can be retrieved which in some cases requires a small number of writes, but far too slow to write any bulk data. Some vendors allow you to continue using Enterprise SSDs when expected power-off data retention is < 3 months, e.g. Toshiba provide a wear indicator which starts at 200 and runs down to 100 at the defined end-of-life, but you can continue using the drive all the way to 0 if you dont't need 3 months power-off data retention (and we have some use cases where we only need a few minutes data retention, so that can be useful).

I am not familiar with how this is handled in consumer grade SSDs and other consumer flash products. However, lower quality firmware can cause more catastrophic failure modes, the worst of which is to lose the logical to physical block translation table during an update (can be triggered by poor handling of power loss or updating the table when running out of spare usable cells). This normally results in a device which can't be accessed at all anymore. Mindful of this, I do try to avoid killing power to consumer flash products until they have been idle for some seconds.

$ sudo parted -l Model: SD NCard (sd/mmc) Disk /dev/mmcblk0: 31,7GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags:

Number Start End Size Type File system Flags 1 4194kB 62,9MB 58,7MB primary fat16 lba 2 62,9MB 31,7GB 31,6GB primary ext4