I recently purchased a 10TB Seagate USB3 drive and it had an IronWolf SATA drive in it. I just did basic functionality tests and then shucked it. I trust the IronWolf drives for reliability and will maintain an off site (encrypted) backup as well, so the reliability of the drive is well within my comfort zone for my purposes. If you are truly concerned about the reliability to the point of wanting to run it through months of infant mortality testing (which may shorten its usable lifetime) then I would highly encourage off site backups as well. All the HDD testing in the world won't help if the location it is in burns down or is destroyed in an earthquake.
This is just my 2 cents. Do what you feel is best for your use case and comfort level. Also, if it is of any help, I usually search the drive model number on the reddit/r/buildapcsales <https://www.reddit.com/r/buildapcsales/> site and see what people have said about it. Lots of folks there shuck drives and mention what type of drive was found in their enclosure. On Thu, Sep 3, 2020 at 2:07 AM <[email protected]> wrote: > I guess that you are hoping to find SATA drive inside the enclosure. > > If true - you might be disapointed as a lot of these drives have native > USB interface under the hood - unless you already know otherwise. > > Additionally - the drive is most likely SMR - so your test should take > that into account and write/read/write/read large blocks. > > Best luck, > Tomas > > On Wed, 2020-09-02 at 22:53 -0700, Larry Brigman wrote: > > In my former life as a test engineer for a disk company, we used > > custom > > testers to stress-test. > > That eventually moved to custom code loaded directly on the device to > > do > > the work. > > When I moved to Linux we used direct-io libraries to write and > > read/verify > > random or patterned data to the drive; in both seq, random and > > butterfly. > > Low-level tools like the sg3-utils have a large set of direct disk > > access > > tools. > > Other tools to use are IOZone and FIO to run a large sample of tests > > over > > and over again. > > > > On Wed, Sep 2, 2020 at 10:30 PM Galen Seitz <[email protected]> > > wrote: > > > > > On 9/2/20 9:43 PM, Keith Lofstrom wrote: > > > > I bought an 8TB Seagate USB3 drive Real Cheap at Costco, > > > > which I will eventually "shuck" to get at the SATA hard > > > > drive inside. > > > > > > > > Voiding the hell out of the warranty, so I would like to > > > > stress test it for a few months before I open the case. > > > > There are many tools (like bonnie++) that can thrash a > > > > hard drive, but they use more CPU than I would like. > > > > > > > > Is there a non-intrusive command-line hard drive test tool > > > > that can stress-test a hard drive for months with minimal > > > > CPU and RAM activity? How do server farms stress test > > > > incoming drives before committing important data to them? > > > > > > I'm guessing it probably doesn't meet your criteria for a stress > > > test, > > > but the SMART long test won't load your system at all, since it is > > > performed by the drive itself. I don't know how well the SMART > > > tests > > > work over a USB interface. I think there was a time when smartctl > > > wouldn't work over USB, but that may have been solved long ago. > > > > > > There's also the badblocks command. I don't know how much it would > > > load > > > your system, but I bet it would be less than a program like bonnie > > > which > > > tests performance. > > > > > > galen > > > -- > > > Galen Seitz > > > [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 > _______________________________________________ > 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
