====== 2017-05-08 - a tale of a no-name SD card ======

i recently had an unusual need -- an SD card, with high capacity, where speed does not really matter. i wanted to put some music on it once and then use it for [[wp>USB]]-based players, so as long as it gives 0.5MB/s, it's just fine((aside from the pain of initial music recording, but this is to be done once a year maybe)). ;) since for this usage, the main criteria was a low price, i've bought 3 cards of this "type":

{{:blog:2017:05:08:sd_card.jpeg?400|no-name SD card}}

no name, no manufacturer, not addresses... nothing. no useful/traceable information on the box either. oh well...

first unpleasant surprise - micro-SD to SD adapters do not work. ok -- screw it. i have plenty of them in the closet. second surprise was more disturbing -- after 4h of putting data on the card... most of it is gone, some files are broken... [[wp>ext4]] did not worked at all. after a lot of trials-and-errors + giving a shot to remaining 2 cards, i started to dig in. each card did NOT report any errors during writes. reads however seemed to return invalid results, but not often. some files had [[wp>MD5]] sums just right, some did not... maybe there is a pattern?

i went down to block level and started //badblock// command, to scan the whole surface of 2, randomly picked cards, during the night. in the morning i was quite shocked to see badblocks reporting ~0.5GB (lit.: half-a-gigabyte!) file with a list of bad blocks! i've quickly written [[https://github.com/el-bart/mini/blob/master/_misc/badblocks_heatmap|script to generate heat-map of bad blocks]], from a generated report. this is what i saw, on both cards:

{{:blog:2017:05:08:sd-1.png?500|heat-map of bad blocks on card 1}}
{{:blog:2017:05:08:sd-2.png?500|heat-map of bad blocks on card 2}}

cards were 64GB, so to keep it readable, each pixel represents 1MB worth of sectors. the heat-maps' key is:
  * green -- all sectors in a given range are valid
  * red -- some sectors in a given range are invalid
  * black -- all sectors in a given range are invalid
  * white -- out of device space (i.e. image padding, to keep it square)

it turns out that first ~310MB of space is ok. rest is just not usable -- and it is **silently unusable**! on both cards, pretty much the same pattern. it suggest it was a deliberate action, taken by a producer, to con customer, by selling "big" SD cards, that cannot really hold what they promise to.

now imagine you bought such a card, put it into a camera and go on vacation. it would be quite a surprise to see majority of your pictures just gone and others (possibly) corrupted!

how can such events be prevented? good question. i was thinking -- maybe there should be a food-like regulation, where each product is obligated by law to have a well-defined producer and/or distributor, that is responsible for quality assurance?

one more note at the end -- aside from the fact that ppl are being cheated dummy SD cards, environment get hit too. this must be produced at a mass scale. some did invest in a dedicated software for such a device, to trick user into thinking card do have some reasonable capacity! then all of this must be packed, labeled, distributed... just to end up in a thrash can, since it is completely useless.

when it comes to me, this was the last time i bought no-name electronics/semiconductors. instead of saving some change, i lost a day worth of work to figure out what is going on and re-test all the cards and re-select all the music i wanted to record there (5MB/s was the I/O speed, btw). lesson learned.