@andyj:
Unless you have a way to have many devices connected at once
Seven 7-Port USB3 hubs all plugged into an eighth hub (49 simultaneous ports)
Granted, we've never run four dozen SD/USB devices for "fake" testing in a single session.
Prime number: reasonable consideration -- probably not
overly important (I'll explain)
Random values: also not
likely necessary for phase 1 read/write tests (again, will explain)
Start from last
SECTOR: Due to the math necessary to calculate bytes per sector, physical versus logical sectors, etc. I figured it may be more prudent to use BYTE addressing since it was available in dd and can be easier to visualize. From the END and work backward might be an option, but I'd still need to create written blocks near the beginning (see below) and it MAY be necessary to ignore the VERY LAST sector if it errors out DD as it may not be a "whole" sector even in valid (albeit, cheap) media.
Explanation: If we can reasonably ensure that the number of writes we're putting onto the flash device will exceed what is (calculated) larger than an assumed/estimated cache, WHAT we actually write is not horribly important -- so writing the same string over and over again (I used a 16 Byte example as it was easy to depict on paper here) is easy to accomplish, to read-verify and it's the same string over and over again, so there's no "logic" necessary to run the comparison. This "should" be the fastest method to push tiny little byte packets onto flash media. Since there's no file system involved, we shouldn't have block sizes to deal with, either - so 16 BYTES should in theory be... 16 BYTES, not 16
KILObytes if that's the current format. As such, Phase 1's read/write test "should" be very quick.
Secondly, more times than not DD will crash (exit with error) while writing to the bogus address to where a read verification won't be an option anyway, so in my mind, random seeds, primes, etc. should not be necessary as they're just CPU cycles spent on trying to fool-proof the system
early on. PHASE 1 just writes to an arbitrary location near the beginning of the flash, jumps in larger increments (say, 1/32 of the entire "reported" flash size) and checks to see if writing to each of these 32 areas comes back without error and with verifying the basic string of text. Additionally, reading from ZERO and working upward here can show us where the cliff exists (the end of the "true" flash storage area) but if it's a fake, not too many consumers are going to care how big it was
supposed to be.
PHASE 2 is all about filling up a fake flash
cache. The amount of DATA we're writing is now less important than the number of TIMES we write to it. This is where your suggestion of writing the ADDRESS as the STRING would likely work out well by prefixing the number with zeros or some other padding we can rely on.
NOTE: Most fakes will fail during these first two phases, both of which
should be reasonably quick and painless.
If the device passes PHASE 1 and PHASE 2, we may then want to move into more of a "byte for byte" mentality; my original post mentions creating 1MB blocks and staggering them across the flash drive at every so many MB in between. We randomly pick one of the first dozen or so write zones as our corruption test. Every X number of writes we then read the written data to make sure it's properly making it to the flash. Every Y number of writes we re-read our corruption test area. Once we make it to the end, we increment our offset and repeat the staggered approach all the while re-reading the same test zone(s) to make sure the first writes we made remain stable. PHASE 3 is more of a reliability test as well as a method to catch overly elaborate fakes - it also takes the most amount of time, of course, since we're potentially writing an entire ###GB flash drive.
@Rich: Your attention to detail is always appreciated!
Yes, I knew seek/skip would both come into play -- at four or so in the morning I'm guessing "who's on first" is a stretch.
Thank you gentlemen; I'm going to let all of this soak in and get an earlier than usual rest tonight - long day tomorrow!
@andyj: I'll get an update your way by roughly the end of the weekend; I haven't finished mod testing and "free time" tends to come and go.