If you set up a new mechanical disk that you take fresh out of the package and slot it into your NAS, do you ask yourself whether the data on it will be safe? I personally enjoy knowing about problems with my storage hardware before it contains any important data, and so do a bunch of folks who run machines with lots of drives in them!
There's a pretty decent procedure that I'd been using to burn-in my HDDs, taken from this forum thread; it was fine in 2014 but these days, HDDs in excess of 18TiB exist, and on those badblocks runs into a limitation of its block offset representation. (Besides, badblocks is really slow.)
Hence, this tool: disk-spinner.
It destructively writes blocks of random data to an entire disk device (or, optionally, just a partition; but you'll probably want the whole drive), then verifies that the data matches what's been written.
Using Rayon, it creates a number of testing threads equal to the number of cores your system has. If you would like to override this for whatever reason, the RAYON_NUM_THREADS environment variable will take precedence over that check.
If any data could not be read exactly as written, it informs you in big letters. That means your disk is bad & you should make use of your vendor's RMA policy. Doesn't it feel great to not run into problems?
This tool is made mainly for linux, but should work on many posix-ish systems; I've tested it on macOS, where it does the thing too.
The Linux platform is privileged a bit in terms of not only my own platform usage (my NAS running zfs on linux and all that) but also safety checking (we use udev to determine various things about the devices under test and error if they look used or non-mechanical), and terminal UI (I am confident only in Linux's ability to return accurate sizes of the block device being tested).
disk-spinner comes with some predictable-garbage generators pre-installed: AES and BLAKE3. On modern CPUs, AES is the more performant of the two (provided your CPU has AES-NI or NEON instructions, which many amd64 and aarch64 CPUs targeted by rust do these days). The AES generator manages about 200-500MB/s of data using one CPU thread, which tends to be enough for testing a few disks at a time. Older CPUs (those lacking the intrinsic instructions that make AES fast) can benefit from the BLAKE3 generator - select it with the --generator=blake3 CLI flag.
However, if you wish to test many disks (say, 75% the number of your available CPU cores), you will quickly find that even very many CPU cores can't saturate all the disks' IO bandwidth, and the process will be very slow. That is where the --generator=shishua RNG comes in: It's a very fast (approximately 5GiB/s fast) and so can satisfy many more disks.
The catch with the shishua generator is that this requires that the shishua CLI tool is available in $PATH and I don't think there are OS distro packages available. When you have made that tool available on $PATH, build disk-spinner with --features shishua-cli (and don't forget --release!) and it should be used as the default generator. The disk-spinner nix package automatically does everything you need to get the shishua-based generator by default.
This tool is for spinning disks; it's also a play on the German word "Spinner" (a goofball), referring to me - a person goofy about disks.
First of all, the 18TiB issue. I'd been using zfs (write random data, zpool scrub) to validate the data in the meantime; but unfortunately, that reserves a good chunk of space on the volume which will remain untested. So, here we are.
I also wanted to make something that does a bunch of error-checking before it'll let me super-destructively overwrite data on a drive: This tool does check that it's running on a bare disk drive with a rotational medium.
Also, performance is not bad at all: The random data that is getting written is generated by encrypting zeroes with AES-128-CTR, based on a key generated from a seed (--seed, or autogenerated). That gets a speed of about 660MiB/s when writing to my SSD.
Plus, it can be run in parallel on multiple disks (spawning one thread per drive) and presents compact output. I like compact output.
A similar technique used here (pipe zeroes into a crypto routine) is being suggested by the folks on archwiki, but the concrete technique (write zeroes via AES-128-CTR based on a deterministic key) comes from my pal @rwg who has done & discarded more super cool hacks than many of us can dream of.