npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

testor-sterone

v0.0.7

Published

Test HDDs for failures.

Downloads

270

Readme

testor-sterone

testor-sterone is a utility which can be used to test HDDs for failures.

Why another test app for HDDs? / The Story

One day one of my disks got kicked out of my NAS RAID. I checked the supposedly bad sector, I checked the S.M.A.R.T. values and did some extended S.M.A.R.T. tests. Everything was ok. So I decided to use some tools to test the drive, for example the one from the drive manufacturer. These tools usually write test data to the disk sequentially, read the data and verify it. And it took hours to complete, just to see that everything was fine. So I put that disk back to the RAID and started the rebuild. But after a short time it got kicked out again. So I repeated all tests, but again everything seemed to be fine.

Then I thought maybe I need to stress the disk to provoke disk failures. This is when testor-sterone was born. Its cross-test jumps on the disk back and forth, writes different patterns, reads and validates the data. And boom! I detected write failures, read failures and sometimes even if writing and reading succeeded, the written and read data did not match.

As this tool might be useful to others, I thought I share it here. And to provide the full package, testor-sterone can not only run the aforementioned cross-tests, it can also write test data sequentially and verify it afterwards ... the traditional way.

Installation

You need to have NodeJS (>= v17) installed.

Then, to install testor-sterone, run:

$ npm i -g testor-sterone

Alternatively you can download the dist/testor-sterone.js file and run it directly using NodeJS.

Requirements

testor-sterone builds on top of other tools to retrieve information about block devices (like HDDs). Those tools must be globally available on your system:

  • Linux: lsblk
  • MacOS: diskutil
  • Windows: powershell.exe (Get-WmiObject cmdlet)
    TODO:/NOTE: Unfortunately WMI returns incorrect device sizes. Thus, a few mebibytes at the end of the device remain untested.

Usage

Note: You must run this tool with super user privileges. Otherwise it cannot write directly to block devices like HDDs.

Note: The following examples were executed on a Linux system. On Windows and MacOS the commands are the same, but especially the pathes of block devices look different (and no sudo on Windows).

At first we look which devices are available:

$ # If testor-sterone was installed via npm:
$ sudo testor-sterone devices

$ # If you downloaded testor-sterone.js manually:
$ sudo node testor-sterone.js devices

The output will look like this

-------------------------------------------------------------------------------
Device: INTEL_SSDSC2MH120A2
Serial: LNEL12345678901ABC
Path:   /dev/sda
Size:   111.79 GiB (120034123776 B)
-------------------------------------------------------------------------------
Device: WDC_WD20EARX-00PASB0
Serial: WD-WCABCD123456
Path:   /dev/sdb
Size:   1863.01 GiB (2000398934016 B)
-------------------------------------------------------------------------------
Device: Samsung SSD 970 PRO 512GB
Serial: S123AB123456789
Path:   /dev/nvme0n1
Size:   476.93 GiB (512110190592 B)
-------------------------------------------------------------------------------

Let's test the device /dev/sdb:

In the following snippet we perform a write-test followed by a read-test.

$ sudo testor-sterone test /dev/sdb
-------------------------------------------------------------------------------
Device: WDC_WD20EARX-00PASB0
Serial: WD-WCABCD123456
Path:   /dev/sdb
Size:   1863.01 GiB (2000398934016 B)
-------------------------------------------------------------------------------
ATTENTION: USE AT YOUR OWN RISK!
-------------------------------------------------------------------------------
Will perform write and read test.
All data on the device will be deleted!
Do you want to proceed? (type uppercase YES) > YES
Writing test data ...
  Speed:     [CUR] 107.39 MiB/s   [AVG] 112.68 MiB/s   [MIN] 107.39 MiB/s   [MAX] 118.71 MiB/s
  Progress:  0.04 %   (884998144 B = 844.00 MiB)
  Elapsed:   00d 00h 00m 07s
  Remaining: 00d 04h 55m 56s

And here we perform a cross-test.

$ sudo testor-sterone test /dev/sdb --mode x
-------------------------------------------------------------------------------
Device: WDC_WD20EARX-00PASB0
Serial: WD-WCABCD123456
Path:   /dev/sdb
Size:   1863.01 GiB (2000398934016 B)
-------------------------------------------------------------------------------
ATTENTION: USE AT YOUR OWN RISK!
-------------------------------------------------------------------------------
Will perform cross (write and read) test.
All data on the device will be deleted!
Do you want to proceed? (type uppercase YES) > YES
Run cross-test using a chunk size of 4.00 MiB and patterns 0xAA, 0x55 ...
  Speed:     [CUR]  92.96 MiB/s   [AVG]  93.39 MiB/s   [MIN]  91.86 MiB/s   [MAX]  95.42 MiB/s
  Progress:  0.00 %   (536870912 B = 512.00 MiB)
  State:     Writing 0xAA to 0 B - 1073741824 B  (0.00 B - 1.00 GiB) using Log2 jumps
  Elapsed:   00d 00h 00m 05s
  Remaining: 00d 22h 48m 02s

Attention: All data on the device will be deleted. Use at your own risk!

Available Options:

The following options are available when running tests:

| Option | Possible values | Default | Description | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | --mode MODE or -m MODE | rw, w, r, x | wr | wr: First write test data to the device sequentially. Afterwards, read the data and verify it.w: Only write test data to the device.r: Read data from the device and verify it. Of course, you should have written test data to the disk before you use the read-mode.x: Use cross-test, i.e. perform a test stripe-wise where we jump back and forth inside the stripe and alternately write, read and verify different patterns, until we move on to the next stripe. | | --output-mode MODE or -o MODE | direct, dsync, normal | Linux, MacOS: directWindows: dsync | Usually you want to bypass as much caches as possible. So in almost all cases you should not change the default output mode. In case you need to change it for some reason, this is the option to go. | | --chunk-size SIZE or -c SIZE | Number of bytes. Suffixes K, M, G may be used to specify Kibibytes, Mebibytes, Gibibytes, respectively. | 4M (4 Mebibytes) | The number of bytes to write/read at once.NOTE: If you use output-mode direct, then the chunk size must be a multiple of 512. | | --stripe-size SIZE or -t SIZE | Number of bytes. Suffixes K, M, G may be used to specify Kibibytes, Mebibytes, Gibibytes, respectively. | 1G (1 Gibibyte) | This option is available in cross-mode only. In cross-mode the disk is tested stripe by stripe. While testing a stripe, the test jumps back and forth within the stripe and alternately writes and reads data. Using this option you can specify the size of those stripes. | | --start POSITION or -s POSITION | Number of bytes. Suffixes K, M, G may be used to specify Kibibytes, Mebibytes, Gibibytes, respectively. | 0 | This option specifies the number of bytes to skip before testing anything. This can be useful in case you had to stop a test and want to resume where it left off. |

Developer notes

To compile the typescript code during development:

$ npm run build

To create a bundle (dist/testor-sterone.js):

$ npm run bundle

To run the tests:

$ npm test