If the disk is SMR (it probably is), then it will have 100GB-200GB CMR write cache.
When you write, that is where the data goes. Later, the disk moves it to the SMR part. So, each write is followed by the disk FW activity/clean up. If you write more data than the cache size, without given the disk time to clean up, you will know. For small, sequential writes with plenty of time between, the performance will be fine. In-place file updates are agony with SMR. Aren't we glad to still have tar around for ideal use mode of these drives!? Tomas On Thu, Sep 3, 2020, 17:53 Keith Lofstrom <[email protected]> wrote: > 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 > _______________________________________________ PLUG: https://pdxlinux.org PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
