Writing to LTO tape, drive cycles constantly during write

Hi All,

I’m trying to write a large file to a LTO (4) tape here’s the command and a status during the write:

mbuffer -i ./bigfile -o /dev/st0 -s 1M -P 80 -m 2G -L --tapeaware

in @ 176 MiB/s, out @ 234 MiB/s, 46.2 GiB total, buffer 95% full, 50% done

During the write the status returned from mbuffer is constantly updating but the drive spins up and down and up and down (or on and off).

Any way to get a constant write stream to the tape drive? What am I doing wrong? TIA!

More info:

dmesg | grep st0

[ 0.623993] scsi host0: ahci
[ 10.677537] st 6:0:0:0: Attached scsi tape st0
[ 10.677538] st 6:0:0:0: st0: try direct i/o: yes (alignment 4 B)
[ 80.817659] st 6:0:0:0: [st0] Block limits 1 - 16777215 bytes.

mt -f /dev/st0 status

drive type = 114
drive status = 1174405120
sense key error = 0
residue count = 0
file number = 0
block number = 0

Welcome!

The spin-up/spin-down behavior is normal for LTO drives, because they need to make multiple passes on the tape to fill it up and the drive needs to slow down and stop momentarily at the ends of the tape.

Something that should be considered is that it may take many dozens to hundreds of passes to fill up a tape, but tape life cycle is measured in end-to-end passes so filling up a tape could use up as many as ~200 cycles out of the 10,000-20,000 cycle limit most tapes have.

Good tip from @twin_savage: even an LTO tape & drive working perfectly will have brief pauses every few minutes as the tape switches directions for another pass. How often are you seeing (or hearing) it?

LTO-4 has a maximum speed of 120Mbps. If you’re seeing around 234Mbps most of the time, your “bigfile” is something that compresses quite well like a text file, disk image, or SQL dump. If it can be compressed more than 2:1, you’ll hit compression speed limits on your LTO drive throughput, and the tape will spin down (possibly quite a lot) because of it. Much better to compress your bigfile (or any other data) in software with pigz/xz/zstd/etc. first, before sending it to tape to avoid this.

Is the buffer staying in the double-digit “% full” range the whole time?

As for other a few suggestions, see my prior post:

Ok, no soft errors :slight_smile:

$ sudo mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x46 (LTO-4).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN

I restored and verified the bigfile from tape. Guess that’s the way it is…

Cheers.

Yep. And the bigfile is a qcow2 virtual machine disk.

Probably needs compression to deal with unused empty disk space before sending to tape. If your CPU is fast enough, you can do it in a pipeline on-the-fly like:

pigz < bigfile | mbuffer -o /dev/nst0 -s 1M -m 2G

If mbuffer shows a steady ~ 120MiB/s output, you’ll know it’s working, and should take less time.

This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.