This test part of the RealDB project. See site at http://www.gillius.org/realdb/

Based on revision 76 of CorruptionTest:

Ran the test a handful of times on the following equipment:
 * Generic "ALLIN1 2.0" multi card reader connected by USB 2.0
 * Ubuntu Linux hardy heron 8.04.1
 * Java 1.6.0_06 JDK to make JAR and run first tests
 * GCJ 4.2.3 to compile Sun Java generated JAR into native executable, used only in last test
 * CorruptionTest revision 76
 * SanDisk 128MB CompactFlash card, probably purchased circa mid 2004, copyright date on label is 2000
   * Formatted Fat16

write
Creating file with timestamp of Sun Jul 27 21:41:11 EDT 2008
...........20%..........40%.....Write failed while writing block 3
Exception in thread "main" java.io.IOException: Input/output error

validate
...........20%..........40%..........60%..........80%..........100%
Blocks good=3, bad_data=1, bad_block_num=0, clear=0
New timestamp Sun Jul 27 21:41:11 EDT 2008 found at block 0
Block 3 failed CRC check.
  Block 3, segment 0 has 261139 non-zero bytes, with the last non-zero byte at 262144.
  Block 3, segment 1 has 30604 non-zero bytes, with the last non-zero byte at 30720.
  Block 3, segment 2 has 0 non-zero bytes, with the last non-zero byte at 0.
  Block 3, segment 3 has 0 non-zero bytes, with the last non-zero byte at 0.

In this example, we fail on the last block in the second segment. The number 30720 is divisible by 2048. If there is an "atomic" unit for the flash card, it could be 512, 1024, 2048 or so bytes. I was realizing something new from the previous tests -- if there is an "atomic unit", then the offset that the file begins on the physical disk is important to make sure that two blocks don't get corrupted, if the data really goes random (as opposed to all old or all new content).

It is also good to note that under Linux and JRE 1.6, the "rwd" mode is supported, because I can see the writes blocking.

validate
...........20%..........40%..........60%..........80%..........100%
Blocks good=3, bad_data=1, bad_block_num=0, clear=0
New timestamp Sun Jul 27 22:03:42 EDT 2008 found at block 0
Block 3 failed CRC check.
  Block 3, segment 0 has 26532 non-zero bytes, with the last non-zero byte at 30720.
  Block 3, segment 1 has 0 non-zero bytes, with the last non-zero byte at 0.
  Block 3, segment 2 has 0 non-zero bytes, with the last non-zero byte at 0.
  Block 3, segment 3 has 0 non-zero bytes, with the last non-zero byte at 0.
Completed validate in 1.480746087 seconds

-------------------

At this point I decided to try the test on the partition itself. In this mode, realdb does not use a file system but instead uses the entire partition as a database. In order to access the parition directly, I ran as root. There may be a way to open up permissions for standard users to do this, but I did not investigate how to do that. Clearing the entire disk of 122 blocks took 55.23 seconds, but writing random data took a little over 100. I wanted to validate that I could write the whole disk.

clear
Creating file with timestamp of Sun Jul 27 22:15:56 EDT 2008
...........20%..........40%..........60%..........80%..........100%
Completed clear in 55.229942076 seconds
validate
...........20%..........40%..........60%..........80%..........100%
Blocks good=0, bad_data=0, bad_block_num=0, clear=122
New timestamp Sun Jul 27 22:15:56 EDT 2008 found at block 0
Completed validate in 0.6522461 seconds
write
Creating file with timestamp of Sun Jul 27 22:17:32 EDT 2008
...........20%..........40%..........60%..........80%..........100%
Completed write in 100.248158696 seconds
validate
...........20%..........40%..........60%..........80%..........100%
Blocks good=122, bad_data=0, bad_block_num=0, clear=0
New timestamp Sun Jul 27 22:17:32 EDT 2008 found at block 0
Completed validate in 0.579757892 seconds

Now comes the test:
write
Creating file with timestamp of Sun Jul 27 22:23:13 EDT 2008
...........20%...Write failed while writing block 33

validate
...........20%..........40%..........60%..........80%..........100%
Blocks good=33, bad_data=1, bad_block_num=0, clear=88
New timestamp Sun Jul 27 22:23:13 EDT 2008 found at block 0
New timestamp Sun Jul 27 22:22:15 EDT 2008 found at block 34
Block 33 failed CRC check.
  Block 33, segment 0 has 261043 non-zero bytes, with the last non-zero byte at 262144.
  Block 33, segment 1 has 261110 non-zero bytes, with the last non-zero byte at 262144.
  Block 33, segment 2 has 153548 non-zero bytes, with the last non-zero byte at 154112.
  Block 33, segment 3 has 0 non-zero bytes, with the last non-zero byte at 0.
Completed validate in 36.876027149 seconds

The greatest common denominator of 154112, that is also a power of 2, is 512 (512*301). It seems that 512 could be the magic number. What the number is exactly is not that relevant, just that I pick a block size large enough and have the file start on an a physical block boundary. Starting at position 0 does that, and likely in the FAT file system the files start on a position divisible by the sector size into the partition (but there is a 512 byte MBR to worry about...).

As a final test, I asserted that the GCJ-generated executable is not able to access the raw disk, as the file's length method reports 0 bytes in this environment, even when run as root.