<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.5">
</HEAD>
<BODY>
M-NPHW64<Jmills@motorola.com> wrote:<BR>
> ALErs -<BR>
><BR>
> Is there a simple read/write test or script I can turn loose on a suspect<BR>
> SATA drive and let it run? There's no data on the disk I care to preserve.<BR>
><BR>
> TIA.<BR>
> ?- Mills<BR>
<BR>
Yes. iozone is both a performance exerciser and a diagnostic benchmark. It has a -d option which causes it to read after write and compare the pattern it put down to what it read back. <BR>
<BR>
It also has dozens of write and read patterns to really beat the snot out of the disk. <BR>
<BR>
We used it extensively a couple of years back when a new Compaq server running Enterprise Redhat kept trashing our Progress DB. Of course Compaq blamed Progress. We talked with the iozone developer at the time and he either was in the process of finishing up the feature; basically we were an early tester. Guess what? iozone's test barfed on a 16GB test file. Eventually we found that flavor of Linux was not properly handling the buffers when the server had more than 4GB of RAM; it put data in the buffers beyond 4GB; it just didn't write them reliably to disk and eventually forgot about them. The final straw was when I created a directory for something, shutdown and restarted the server, and the directory wasn't there after reboot. When we cut the server back to 4GB of RAM it worked fine. <BR>
<BR>
Now our SOP on building a new server is to always run <BR>
<BLOCKQUOTE>
nohup iozone -a -g 16G -r 8 -+d &<BR>
<BR>
</BLOCKQUOTE>
on all filesystems of any new server before we put databases on it. Note that since linux is buffering i/o, you should make the test file size as large as you have time for.<BR>
<BR>
Now, it sounds like you really suspect some specific portion of the drive surface has become suspect. If so, as other have suggested, the smartctl diagnostics should show you records of prior sector failures that have been mapped out. That would be more useful than what I'm suggesting. It would take weeks for iozone to run a 250GB test on a 256GB drive. <BR>
<BR>
Neal Rhodes<BR>
MNOP Ltd
</BODY>
</HTML>