On 9/2/20 9:43 PM, Keith Lofstrom wrote: KL> ... Is there a non-intrusive command-line hard drive test KL> tool that can stress-test a hard drive for months with KL> minimal CPU and RAM activity? ... On Wed, Sep 02, 2020 at 10:30:23PM -0700, Galen Seitz wrote:
GS> ... I don't know how well the SMART tests work over a USB GS> interface. I think there was a time when smartctl wouldn't GS> work over USB, but that may have been solved long ago. ... Thanks, Galen! "smartctl" still doesn't work over USB, or anyway not with a 3.10.0 kernel. Sigh. GS> There's also the badblocks command. I don't know how much GS> it would load your system, but I bet it would be less than GS> a program like bonnie which tests performance. "badblocks" DOES work - though I used a wrapper: e2fsck -cc -f -y /dev/sdc2 # (99% of the hard drive) This is very slowly grinding away: Checking for bad blocks (non-destructive read-write test) Testing with random pattern: 0.75% done, 1:24:28 elapsed. (0/0/0 errors) ... and monopolizing one CPU core (load average 1.15), but otherwise behaving itself. I estimate that this will take about 8 days to complete one pass on the 8TB partition. I presume that shingled writes (necessitating rewrites of huge blocks of data for every byte written, yikes!) are responsible for the slow speed. The USB3 drive must be a busy little beaver, though it is merely warm to the touch. Not bad for a fanless plastic case cooled by convection. Shingled write probably won't slow down my intended use (dirvish/rsync backups) terribly much. I hope. Those transactions are mostly reads, and a zillion new symlinks in the directories, which I assume are buffered in RAM by the kernel. I hope, I hope. I'll see how this behaves overnight, when backups and spamd run (using two other drives). I may have a different opinion of e2fsck/badblocks behavior in the morning. A month from now, after three or four passes of e2fsck/badblocks, I will try some rsync tests, and see how much that performance suffers. If shingled write is the wave of the future, I should be prepared to adapt. Thanks again! Keith -- Keith Lofstrom [email protected] _______________________________________________ PLUG: https://pdxlinux.org PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
