Hacker News Reader

Comment by brazzy | Hacker News Reader

> Counterfeit cards correctly report the capacity shown on the packaging, but actually contain far less. You won’t notice this until the card fills up unexpectedly quickly.

Oh, it's much worse than that. Counterfeit cards are often manipulated to lie to the OS about their capacity as well. They don't "fill up" at all, they just throw away your data, or overwrite it silently.

View on HN

This is my experience. Bought an SanDisk card to pop in my phone before I went on holiday. Changed my camera settings to save to the SD card. Great. I can stop worrying about filling up my phone's internal storage with photos now.

Then the card corrupted all of my photos.

It must've been a counterfeit. SanDisk is a reputable company headquartered in US owned by a US company. I don't know consumer law (and IANAL in general) but I'd imagine if they were selling fraudulent sd cards they'd probably get hit with fines, a class action lawsuit, and possibly worse.

Happened to me. Before we blame SanDisk the problem exists in older Andriod OS.

That is downright evil. I suppose in order to find an evil card one would have to fill it with a file and then verify that files integrity, a very time consuming process form larger cards.

Not to mention that counterfeit cards are normally much slower, further increasing the tediousness of this process.

Yeah that's the only guaranteed way to find them I've found. There's a couple programs out there that do exactly that. Just start writing files to the SD card and read then read them back. I think they should be a bit more intelligent though, seems like right now they write the whole value you enter as the stated/test value then try to read it back, seems like you could detect bad devices much sooner by doing smaller read tests at set intervals.

the German Computer magazine heise made a tool[0] to verify the capacity by filling it up with random files:

[0] https://www.heise.de/download/product/h2testw-50539

You don't even need such a tool if you're on mac/linux or have msys/cygwin/WSL installed on windows. just do

    dd if=/dev/urandom bs=1048576 count=5000 | tee test.bin | md5sum

(substitute bs=1048576 count=5000 with the actual size of the sd card) then do

    md5sum test.bin

and check whether the two hashes match.

Watch out there: the kernel will cache what it wrote out, and all you'll end up checking is the cache and not the card. dd has a "nocache" option but it's only a request. "direct" might work; I don't know.

Maybe someone will come along and provide references to a a definitive answer on what the behaviour will be.

My point is: it's not trivial to ensure that you're actually testing the right thing.

The trivial solution is to to do the two MD5 sums on two different machines.

Wouldn't removing the card, putting it back in on the same machine and then doing your second hash be sufficient?

You can always unmount and mount the SD card between writing and verifying. The unmount should force the kernel to truly flush everything and do the physical write.

> The unmount should force the kernel to truly flush everything and do the physical write.

True, but this doesn't necessarily guarantee that the subsequent read will come from the card and not the cache.

It might as currently implemented; I don't know. But without specific evidence that it does and will continue to do so indefinitely, I wouldn't assume it for verification purposes.

I make the same point again: it's not trivial to ensure that you're actually testing the right thing.

I would hope that unmounting invalidates the cache, because the kernel can't know that the device wasn't modified between mounts. I like the sibling's idea of using two separate computers though.

In any case, if one reboots the computer, that has to remove that possibility.

The kernel is still in control of the underlying block device, and handles all reads and writes through that block device even when it is unmounted. So it can know that the device wasn't modified between mounts (or, more likely, it'll keep the block device cache maintained).

Unplugging and replugging the card really should invalidate the cache though.

This discussion got me thinking that it might be possible that storage devices might expose a datum that lets the kernel know if there were any writes since it last saw the storage device. Something like total number of writes to the device, last modified time, or something. I'm just wondering out loud. It really seems safest to reboot the computer to destroy whatever cache one might have.

Maybe eject the card between tests?

Add the `oflag=sync` flag to dd.

Or instead of files just write to the block device with one big random file with the supposed byte-accurate size of the device, then read it back and compare. Something like:

  dd bs="$(blockdev --getsize64 "$device")" count=1 if=/dev/urandom of=random-file
  dd if=random-file of="$device"
  cmp random-file "$device"

Using cmp instead of something like md5sum is better since it would stop on the first differing byte, instead of reading the whole thing for both.

EDIT: I'm not sure if my use of dd's bs and count is a good idea, though. It might be better to do:

  head -c "$(blockdev --getsize64 "$device")" /dev/urandom > random-file

to get more reasonable buffer sizes. Documentation on head says -c works on bytes, not characters, so that's good.

For that second line, I often prefer to do:

  pv random-file > "$device"

to get a neat progress bar.

EDIT 2: As discussed in other threads, one should make sure to invalidate the kernel's cache of the device between steps 2 and 3. My safest bet on how to do that is to reboot the computer.

Reply on news.ycombinator.com