STRESSANT(1)

📦
version 0.8.0 · 3 versions
, in ubuntu resolute, ubuntu stonking

💖 NAME 💖

stressant — ok bestie, this is the Stressant Documentation and honestly? it's giving "your laptop is about to get the workout of its life". ✨

🌸 SYNOPSIS 🌸

stressant [-h] [--version] [--log [PATH]] [--email EMAIL] [--smtpserver
HOST] [--smtpuser USERNAME] [--smtppass PASSWORD] [--no-information]
[--no-disk] [--smart] [--diskDevice PATH] [--jobFile PATH] [--overwrite]
[--writeSize SIZE] [--directory PATH] [--diskRuntime DISKRUNTIME] [--no-cpu]
[--cpuBurnTime TIME] [--no-network] [--iperfServer HOST] [--iperfTime TIME]

🦋 DESCRIPTION 🦋

So stressant is a simple yet complete stress-testing tool. What does that mean in human words? It forces a computer to run a whole series of tests, using well-known Linux software, to sniff out possible design or construction failures. Basically it bullies your hardware (lovingly 💅) until it confesses its secrets.

✨ OPTIONS ✨

Every single one, no skips, we're doing the full thing bestie 🫶

  • -h, --help — show this help message and exit. the classic "help me I'm lost" move.
  • --version — show program's version number and exit. main character announcement energy 👑
  • --logfile <PATH> — write reports to the given logfile. default is stressant-$HOSTNAME.log so your hostname gets a little cameo.
  • --email EMAIL — send the report by email to the given address. 📧
  • --smtpserver HOST — SMTP server to use. if the port isn't the default, use a colon to specify the port number; default port is 25. it will attempt to use STARTTLS to secure the connection and will fail if that's unsupported. default: deliver using the --mta command.
  • --smtpuser USERNAME — username for the SMTP server. default: no user.
  • --smtppass PASSWORD — password for the SMTP server. default: prompted, but only if --smtpuser is specified.
  • --no-information, --information — gather basic information. default: True.
  • --no-disk, --disk — run disk tests. default: True.
  • --smart, --no-smart — run SMART tests. default: False.
  • --diskDevice PATH — device to benchmark. default: /dev/sda.
  • --jobFile PATH — path to the fio job file to use. default: /usr/share/doc/fio/examples/basic-verify.fio.
  • --overwrite — actually destroy the given device. default: False. read that again bestie. 😭
  • --writeSize SIZE — size to write to disk, bytes or percentage. default: 100M.
  • --directory PATH — directory to perform file tests in, created if missing. default: None.
  • --diskRuntime DISKRUNTIME — upper limit for disk benchmark. default: 1m.
  • --no-cpu, --cpu — run CPU tests. default: True.
  • --cpuBurnTime TIME — timeout for CPU burn-in. default: 1m. 🔥
  • --no-network, --network — run network tests. default: True.
  • --iperfServer HOST — iperf server to use. default: iperf.he.net.
  • --iperfTime TIME — timeout for iperf test, in seconds. default: 60.

🎀 EXAMPLES 🎀

Small run load with defaults:

stressant

Very fast test, useful to run if you are worried about crashing the machine:

stressant --writeSize 1M --cpuBurnTime 1s --iperfTime 1

Extensive test with complete disk wipe and SMART long test:

sudo stressant --writeSize 100% --overwrite --cpuBurnTime 24h --smart
# wait for the prescribed time, then show the SMART test results:
sudo smartctl -l selftest

Network test only on dedicated server:

stressant --no-information --no-cpu --no-disk --iperfServer iperf.example.net

Send test results by email:

stressant --email person@example.com

If the mail server refuses mail from your location, you can use another relay (password will be prompted):

stressant --email person@example.com --smtpserver submission.example.net --smtpuser person --smtppassword

The stressant-meta package also depends on other tools that are not directly called by the automated script above, but are documented below. The meta-package also suggests many more useful tools.

🧹 Wiping disks

Danger: Wiping disks, just in case it's not totally obvious, will DELETE DATA on the given file or device. DO NOT run ANY command in this section unless you are sure you are writing to the CORRECT DEVICE and that you REALLY want to DESTROY DATA. like, for real for real. 🙈

As mentioned above, the stressant commandline tool can be used to directly wipe a disk with the fio(1) command, which is actually a disk-testing command that is abused for that purpose. You may not have fio(1) installed on your machine, however, so you may also use the venerable badblocks(8) command to test disks, without wiping them:

badblocks -nsv /dev/sdc

You can also wipe disks with the -w flag:

badblocks -wsv /dev/sdc

Be aware, however, that the effect of this will vary according to the physical medium. For example, data may be recovered old spinning hard drives (HDD) if only the above technique is used. For that purpose, you should use a tool like nwipe(1) that erases disks using multiple passes and patterns:

nwipe --autonuke --nogui --method=random --verify=off --logfile=nwipe.log /dev/sdc

The above will also blank the drive at the end. A simpler version that will be faster and less paranoid would be:

nwipe --autonuke --nogui --method=zero --noblank --verify=off --logfile=nwipe.log /dev/sdc

Note that both badblocks and nwipe are going to fail on flaky or failing drives. For that, you might want to try ddrescue(1) instead, as it supports resuming from an existing position with a "map" file. This command will write zeroes on /dev/sdc, for example:

ddrescue --force --pause-on-error=1 /dev/zero /dev/sdb sdb.map

Note that it may also fail on I/O error, but restarting the command will at least resume from where it left off. Also note that using it that way is not exactly the "right" way, as it will estimate the remaining time based on the size of /dev/zero which will be obviously incorrect.

Those tools are also ineffective on solid state drives (SSD) as they have a more complex logic layer and different layout semantics. For this, you need to use a "ATA secure erase" procedure using the hdparm(8) command:

hdparm --user-master u --security-set-pass Eins /dev/sdc
time hdparm --user-master u --security-erase Eins /dev/sdc

More information about this procedure is available in the ATA wiki at https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase.

Note: The "secure erase" procedure basically delegates the task of erasing the data to the disk controller. Nothing guarantees the destruction of that data, short of physical destruction of the drive. See this discussion at https://serverfault.com/questions/199672/secure-delete-on-ssd for more information. This blog post at https://computer.rip/2021-07-26-rip-those-bits-to-shreds.html also provides historical background on those various techniques and argues that only physical destruction can reliably erase data on SSDs. 💀

For a fast wipe that can be done in an emergency, you can use the wipefs(8) command (available at https://manpages.debian.org/wipefs, part of the util-linux package, https://tracker.debian.org/pkg/util-linux) to erase partitions and LUKS header. This will wipe the partitions on /dev/sdc, for example:

wipefs -af /dev/sdc

Note that to wipe a partition's LUKS headers, however, you need first to wipe the actual partition directly, something like this:

wipefs -af /dev/sdc3

The latter is particularly useful to destroy encrypted partitions in a hurry, as the keys are basically required to recover the rest of the data, assuming someone can crack the key slot, of course.

📊 Benchmarking disks

A good way to test disks is to wipe them, as above, but that's obviously destructive. Sometimes you might want to just test the disk's performance by hand, without wiping anything. Stressant ships with fio(1) and bonnie++(1) for that purpose. The latter is probably the simplest to use:

bonnie++ -s 4G -d /mnt/disk/ -n 1024

Make sure the file size (-s) is at least twice the main memory (see free -h). The /mnt/disk directory should be writable by the current user as well.

Stressant itself, when disk tests are enabled, will run the following commands:

dd bs=1M count=512 conv=fdatasync if=/dev/zero of=/mnt/disk/testfile
dd bs=1M count=512 conv=fdatasync if=/mnt/disk/testfile of=/dev/null
hdparm -Tt /dev/disk
smartctl -t long /dev/disk

Those provide a quick overview of basic disk statistics as well.

More elaborate workloads can be done with fio. A simple benchmark could be:

fio --name=stressant --group_reporting --directory=/mnt/disk --size=100M

That is a basic read test. The result here, on a Western Digital Blue M.2 500GB Internal SSD (WDS500G1B0B) with LUKS encryption, LVM and ext4, looks like:

Run status group 0 (all jobs):
   READ: bw=267MiB/s (280MB/s), 267MiB/s-267MiB/s (280MB/s-280MB/s), io=100MiB (105MB), run=374-374msec

Disk stats (read/write):
    dm-3: ios=323/0, merge=0/0, ticks=484/0, in_queue=484, util=70.99%, aggrios=511/0, aggrmerge=0/0, aggrticks=764/0, aggrin_queue=764, aggrutil=76.86%
    dm-0: ios=511/0, merge=0/0, ticks=764/0, in_queue=764, util=76.86%, aggrios=511/0, aggrmerge=0/0, aggrticks=547/0, aggrin_queue=576, aggrutil=73.55%
  sdb: ios=511/0, merge=0/0, ticks=547/0, in_queue=576, util=73.55%

A more realistic workload will ignore the cache (--direct=1), include random (--readwrite=randrw) or sequential writes (--readwrite=readwrite), and parallelize the test to put more pressure on the disk (--numjobs=4):

$ fio --name=stressant --group_reporting --directory=test --size=100M --readwrite=randrw --direct=1 --numjobs=4
Run status group 0 (all jobs):
   READ: bw=45.8MiB/s (48.0MB/s), 45.8MiB/s-45.8MiB/s (48.0MB/s-48.0MB/s), io=199MiB (209MB), run=4346-4346msec
  WRITE: bw=46.2MiB/s (48.5MB/s), 46.2MiB/s-46.2MiB/s (48.5MB/s-48.5MB/s), io=201MiB (211MB), run=4346-4346msec

Disk stats (read/write):
    dm-3: ios=49674/50087, merge=0/0, ticks=10028/3912, in_queue=13972, util=97.22%, aggrios=50982/51423, aggrmerge=0/0, aggrticks=10204/3852, aggrin_queue=14092, aggrutil=96.62%
    dm-0: ios=50982/51423, merge=0/0, ticks=10204/3852, in_queue=14092, util=96.62%, aggrios=50982/51423, aggrmerge=0/0, aggrticks=9042/2598, aggrin_queue=11224, aggrutil=92.54%
  sdb: ios=50982/51423, merge=0/0, ticks=9042/2598, in_queue=11224, util=92.54%

There is, of course, way more information shown by the default fio output, including latency distribution, but those are the numbers people first look for.

Parameters can be stored in a job file, passed as an argument to fio. Examples are available in /usr/share/doc/fio/examples.

Stressant itself actually runs the equivalent of this:

fio --name=stressant --group_reporting --runtime=1m <(sed /^filename=/d /usr/share/doc/fio/examples/basic-verify.fio ; echo size=100m) --filename=test

📝 Note

okay so there are, like, so many other ways to test disks, obviously. Specifically? cute little simple tools like disk-filltest (find it at https://panthema.net/2013/disk-filltest/) might get added to this whole thing someday, but only if they actually make it into Debian (track that drama at http://bugs.debian.org/949307). 💅

🔍 Testing disks

so the stuff above technically tests disks in the sense that it stares at how they perform, but ngl it's way more of a benchmark than an actual "test". For the real testing tea, stressant will do a smartctl run if you hand it the --smart argument. and what it's actually doing? this:

smartctl -t long /dev/sdX

then you can use smartctl -l selftest /dev/sdX to keep an eye on the progress, bestie. ✨

but 😭 this does not work for all drives. for example, it may just fail on external USB enclosures. rude.

and smartmontools's NVMe support (peep it at https://www.smartmontools.org/wiki/NVMe_Support) is, like, particularly limited. nvme-cli (https://github.com/linux-nvme/nvme-cli) might be able to handle those drives way better. in theory it should support running tests with:

nvme device-self-test /dev/nvme0

but in practice that often just flops, because the devices sometimes don't support self-test at all. 💀 so instead you can look at the smart-log:

nvme smart-log /dev/nvme0

if the num_err_log_entries entry is non-zero, then you can go peek at the actual log:

nvme error-log /dev/nvme0

Note

the stuff above doesn't actually explain how to interpret the output of those commands, and honestly it probably should. sorry. 🙈

🌸 Testing flash memory

flash memory cards are known to sometimes be "fake" — like, they misreport the actual capacity of the card or the bandwidth that's available. so the stressant distribution therefore recommends a tool called f3 (http://oss.digirati.com.br/f3/) which lets you perform tests on the memory card. for example, this is a probe on an honest memory card:

$ sudo f3probe --destructive --time-ops /dev/sdb
F3 probe 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Good news: The device `/dev/sdb' is the real thing

Device geometry:
             *Usable* size: 30.00 GB (62916608 blocks)
            Announced size: 30.00 GB (62916608 blocks)
                    Module: 32.00 GB (2^35 Bytes)
    Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
       Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 4'57"
 Operation: total time / count = avg time
      Read: 3.07s / 4815 = 637us
     Write: 4'51" / 4192321 = 69us
     Reset: 324.5ms / 1 = 324.5ms
⚠️ Warning: just like the --destructive flag is hinting at, this is gonna destroy the data on the card. so back your data up somewhere else before you do these tests, fr fr. no cap. 😭

also note that older versions of f3probe(1) (6.0 or earlier) are gonna have trouble doing their job unless the card is connected through a USB reader. newer versions can deal with normal block devices, provided that you pass the magic --reset-type=2 argument. here's an example of that, on a fake MicroSD card that's labeled and announced as 32GB but is actually closer to 16GB:

root@curie:/home/anarcat/backup# ~anarcat/dist/f3/f3probe --destructive --time-ops --reset-type=2  /dev/mmcblk0
F3 probe 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Bad news: The device `/dev/mmcblk0' is a counterfeit of type limbo

You can "fix" this device using the following command:
f3fix --last-sec=30983327 /dev/mmcblk0

Device geometry:
             *Usable* size: 14.77 GB (30983328 blocks)
            Announced size: 31.25 GB (65536000 blocks)
                    Module: 32.00 GB (2^35 Bytes)
    Approximate cache size: 7.00 MB (14336 blocks), need-reset=no
       Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 2'29"
 Operation: total time / count = avg time
      Read: 1.57s / 32937 = 47us
     Write: 2'27" / 200814 = 736us
     Reset: 2us / 2 = 1us

to repair the device, you can repartition it real quick with the f3fix(1) command, just like the output recommends:

f3fix --last-sec=30983327 /dev/mmcblk0

you're also gonna need to reformat the partition so the new size actually gets taken into account. for example, if this is a FAT32 filesystem:

mkfs.fat /dev/mmcblk0p1

you can also do bandwidth tests with f3read(1) and f3write(1):

pmount /dev/sdb1
f3write /media/sdb1
f3read /media/sdb1

and this lets you detect hidden caches and fake sizes directly too. iconic. 👑

🌐 Network performance testing

the --iperfServer option of stressant runs a bandwidth test against a predefined (or specified) server. and you can, of course, just call iPerf (https://en.wikipedia.org/wiki/Iperf) directly to run your own client/server tests, to hunt down issues in specific routes on the network. the iperf3 package was chosen over the older iperf because public servers are available so the test can work automatically. iperf3 also has interesting performance features like --zerocopy and --file, so go see iperf3(1) for the details. ✨

to run a test, start a server:

iperf3 --server

on another machine, connect to the server:

iperf3 --client 192.0.2.1

this runs a TCP test. you can specify a UDP test on the client and disable bandwidth limitations (otherwise UDP tests are limited to 1 Mbit/s):

iperf3 -c 192.0.2.1 --udp --bandwidth 0

to simulate a DDOS condition, you can try multiple clients and run the test for a longer period:

iperf3 -c 192.0.2.1 -u -b 0 --parallel 50 --time 30

👀 SEE ALSO

hdparm(8), smartctl(8), dd(1), fio(), stress-ng(1), iperf3(1)

💖 Author

Antoine Beaupre

2017, Antoine Beaupre

and that's the whole vibe, bestie — this page is from Sep 20, 2025, and it's STRESSANT(1). go stress-test something responsibly, mwah 🫶💜

📦 where this page comes from