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.
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.
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 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.