Magic Banana,
it is valid to question any test setup :)
Right now I hit the 500th writing cycle without issues. We are approaching
the 0.5 TB border.
Anyone who is in doubt about the approach the script now works is free to add
another write cycle from /dev/zero to wipe the filesystem on the USB.
I am unsure what you mean by "..the new write confirms what was on the
drive..". Shure, every write cycle will overwrite the data in from the
previous run with identical data but this doesn't matter. To my understanding
a typical failure of the flash media will lead to an I/O error for the
corresponding Inode. Thus the written randon data file will not be identical
with the complete file in the ram disk.
1st) The file will be much smaller than the source file
2nd) Even if the rest of the USB stick is still filled up with the data from
the previous run, they do not belong to the target file. An I/O error almost
always causes imediate stopping of the copying process.
Both things above lead to different MD5 checksums compared to the previous
runs. Thus you can find out the sticks corruption.
In theory one could simply fill up the flash drive with data from /dev/zero
and calculate the MD5 checksum at each run. Every corruption in the
filesystem will lead to diverging MD5 checksums compared to the previous run.
BTW: I switched away from deleting the target file and simply do a cat
/dev/null > target file to "reset" it.
