I did something similar but I use the same 30 GB data set with known md5s. I repeatedly go through the files and check the sums. You would be surprised (or not) but after 24h of this some drives start giving wrong sums. And this is on systems that have been put through extensive burn-ins with prime95 and memtest and more. For example I have this one 500gb drive from WD blue that after a while throws bad sums on this test. Amazing stuff, I have kept the drive for science, and not rma'ed it. Cool site btw. VERY COOL!

The number of hard disk produced in the last five years is huge. Of course, this is the same number of hard disks that will most probably fail in the next five years, possibly with catastrophic consequences for the particular user or business.

The simple tool disk-filltest can help, together with S.M.A.R.T. monitoring, to check disks periodically and thus be forewarned about coming failures. The function of disk-filltest is simple:

Write files random-######## to the current directory until the disk is full.

Read the files again and verify the pseudo-random sequence written.

Any write or read error will be reported, either by the operating system or by checking the pseudo-random sequence.

Optionally, delete the random files after a successful run.

The method is simple and effective, however, it of course does not verify other files on the disk. That is a different task, which can be solved efficiently using digup (a Digest Updating Tool).

Another useful side-function of disk-filltest is to measure read/write speed while filling the disk. Slow speeds may also indicate a future failure, or just bad disk controlling.

The program runs on Linux, Windows and probably any other POSIX-compatible system. The whole source code is just one .c-file.

Short Usage Guide

Just call disk-filltest on the command line, optionally adding -u. The tool will fill the current directory with random data files. About 575 GiB were free in the example directory, as seen from the run below:

The only option requiring more explanation is -U. In this mode, the tool will create the files random-######## as usual, but will immediately unlink() them from the file system (the directory stays empty). On Linux this is possible, because the tool can keep the file descriptors open and perform the usual write/read/verify sequence. The mode is very useful for batch checking, because the system will automatically free the used disk space when the program finishes, whether successfully or with an error!

ChangeLog

2013-05-07 - Timo Bingmann - v0.7.1

Fixed bug on Windows by adding O_BINARY open flag: Windows reads by default files as text files and does some weird character translations.