I am testing out a new Quantum Ultrium 8 Tape and Drive. I see the listed maximum uncompressed and compressed data rate, respectively, are 360 MB/s and 900 MB/s. How can I observe/demonstrate this level of performance most simply? I was trying this:

dd if=/dev/urandom of=/dev/shm/random-data bs=64M count=16

while [[ $SECONDS -lt $end ]]; do
    dd if=/dev/shm/random-data of=/dev/nst0 bs=1M count=1024

Chunk of the output:

1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 7.66494 s, 140 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 8.10491 s, 132 MB/s

I got an average speed of 126 MB/s. When I tried to test the compressed data rate, by filling up another file in /dev/shm/ with 1GB from /dev/zero and doing the same loop, I got an average of 282 MB/s.

Is there another simple way to observe/demonstrate the expected data rates (or at least just the uncompressed speed)? What is causing the limitation I'm observing?

  • 1
    You're probably comparing apples to oranges. The data rates provided by manufacturers are typically the physical maximum supported by the medium/media with absolutely no idle time or gaps. You're measuring not at the drive but overall transfer time and rates that involve several interfaces, additional overhead, and unknown amount of buffering. FWIW the spec sheet I looked at has slightly lower transfer rates: cdn.allbound.com/iq-ab/2020/02/09222012/… BTW a huge block size doesn't help since the device cannot handle it.
    – sawdust
    Mar 3, 2020 at 23:49
  • What is a good block size that the device can handle? Do you know how I can compare apples to apples? I mean is there some kind of library or command that does reporting that would test the tape speed while accounting for the overhead? Mar 4, 2020 at 0:21
  • You'll have to read the tech manual for the actual block size(s). Typical physical media limit the block size to a few K bytes for reliable error detection (and correction). Measuring apples may not be worth the effort because you have to use the device in a computer system rather than by itself. You can try different transfers, see stackoverflow.com/questions/6161823/… Using dd to write from /dev/zero or read to /dev/null (with reasonable blksize) should result in fastest transfer times/rates that you can expect from a block device.
    – sawdust
    Mar 4, 2020 at 0:47
  • Well, I'm only interested in the tape speed, and writing from /dev/zero to /dev/null will not touch the tape, so I don't think that will help me. I guess what you're saying is that dd is more measuring the speed of the block device and not the tape alone? Mar 4, 2020 at 19:47
  • You're just skimming or misreading what I wrote. You would need an oscilloscope and access the logic boards to measure the transfer rate of the medium. I've done similar for disk drives in a previous job.
    – sawdust
    Mar 7, 2020 at 1:30

1 Answer 1


You can observe transfer rate with tapestat Linux command. Here is a man page.

The tapestat command is used for monitoring the activity of tape drives connected to a system.

The tapestat report provides statistics for each tape drive connected to the system. The following data are displayed: ... kB_read/s | MB_read/s The amount of data read expressed in kilobytes (by default or if option -k used) or megabytes (if option -m used) per second averaged over the interval.

For example, I would firstly create dummy data (e.g., 10GB) with /dev/urandom and store it under disk system which is faster enough than LTO's maximum transfer rate. In this specific case, disk's transfer rate shall be >360MB/sec. I would recommend SSD or tmpfs to avoid any bottleneck. Then, write the dummy data to LTO-7 media with tar, something like tar -cvf /dev/st0 dummy_data. Just after starting write process, you should invoke tapestat 1, which will show averaged transfer rate every second.

If output is less than 360MB/sec, there should be a bottleneck in your system. It can be due to SAS card speed, disk speed, internal bus speed, or even your tape drive/media is about to fail.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.