5 ms·
So this always overwrites the device to test it, and I was wondering if that was necessary (say, you had started using it). Presumably you only need to write at
by ajb 2y ago
So this always overwrites the device to test it, and I was wondering if that was necessary (say, you had started using it). Presumably you only need to write at most N+1 blocks, where N is the number of blocks the device actually has.l, in order to detect exaggeration. But at that point the fake device will have overwritten all of your files anyway, even if they were theoretically on different blocks (of the exaggerated inventory). So I guess the minimum harm to test a device is to hash all your files, then write at most N+1 (unused) blocks, stopping after each to check if any of your files got harmed. In theory that risks at most one block...
Of course, it's better to back up the suspect one.
- ThatPlayer 2y agoThis also has the option of f3probe: https://fight-flash-fraud.readthedocs.io/en/latest/usage.html#f3probe-the-fastest-drive-test https://fight-flash-fraud.readthedocs.io/en/latest/usage.htm...
- lxgr 2y ago> hash all your files, then write at most N+1 (unused) blocks, stopping after each to check if any of your files got harmed That strategy adds O(n^2) reads on top of O(n) writes, though. Even reads don't come for free on modern multi-level cell NAND (due to read disturb), and for just a thousand blocks, you'd end up reading the first block a million times. That's to say nothing of the time this would take.
- deleted 2y ago[deleted]
- ajb 2y agoYou're right, this is a non-starter. I should stop posting late at night. The owner of a suspect device just needs to bite the bullet and use a destructive method.
- justinclift 2y agoFor a new device (ie no existing files on it), wouldn't the simplest approach be to full block 1 (whether 512 or 4k bytes) with a series of "1"'s, block 2 with a series of "2"'s, (etc). ie incrementing the number that gets written as the block number being written to is written. Reading that back (either the full device or a random sample) should pretty quickly identify whether things are still in their expected location.
- mark254 2y agoWell, with the remaining trust available at this point you might just as well use something cryptographically secure, like encrypted ones, twos, or simple HMACs of the block number. A too-simple scheme is likely to be detected (and bypassed!) by the firmware a nearly no time.
- justinclift 2y agoSure, that's a decent idea too. :)
- deleted 2y ago[deleted]
- jasomill 2y agoSimpler: 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 2y agoI 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)
- 2y ago
- wakawaka28 2y agoYou are supposed to check an empty device. Some of the fake ones have firmware that will silently delete files or else fake writes. If you load it with data before confirming it is legit, you are likely to lose that data.