Hacker News Reader

Comment by gruez | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com