Well, with the remaining trust available at this point you might just as well us...

jasomill · 2024-09-13T20:45:20 1726260320

Simpler: fill the drive with random data, hashing as you go, flush the kernel's buffer cache, hash the entire contents of the drive, and compare.

Conceptually,

  # tee /dev/DEVICE </dev/random | sha256sum
  # echo 1 > /proc/sys/vm/drop_caches
  # sha256sum /dev/DEVICE

though I wouldn't expect this exact command sequence to work unless tee's buffer size divides /dev/DEVICE's capacity and tee errors out writing past the end of /dev/DEVICE before writing to stdout.

blibble · 2024-09-13T22:58:12 1726268292

I did exactly this earlier last week

the drive size divided by 4MB, so dd with bs=4M and fixed count

(with oflag=direct you don't even need to drop caches)

justinclift · 2024-09-14T02:11:50 1726279910

Oh, that's a clever way of doing things.

The "write the block #'s to the given block" would help identify where a fraudulent device goes wrong.

But for just checking if a device is storing data 100% correctly then your way would probably be more robust. :)

justinclift · 2024-09-13T09:31:34 1726219894

Sure, that's a decent idea too. :)