When we attempt to use tar to write data to an LTO-5 tape, we get the following error. The device starts to write, and then fails. See the tar command and output, followed by the dmesg output. I included the mt status as well. Any help is appreciated.

This is an Ultrium 3280 LTO5 drive connected through a SAS interface on RHEL 6. We tried a second drive, and second tape. These are brand new tapes, and new drives.

Both of the following commands run without any issues.

sudo mt -f /dev/st0 stsetoptions scsi2logical
sudo mt -f /dev/st0 erase

mt status provides the following

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 0x58 (no translation).
Soft error count since last status=0
General status bits on (41010000): BOT ONLINE IM_REP_EN

When we attempt to write some output to the drive, we get the following. The device acts as if it is writing, lights start flashing and starts making noise.

sudo tar cvf /dev/st0 /vader
tar: Removing leading `/' from member names
tar: /dev/st0: Cannot write: Input/output error
tar: Error is not recoverable: exiting now

Here is dmesg

mptbase: ioc0: LogInfo(0x31120403): Originator={PL}, Code={Abort},
SubCode(0x0403) cb_idx mptscsih_io_done
LSI Debug log info 31120403 for channel 0 id 2
st0: Error 80000 (driver bt 0x0, host bt 0x8).

Does anyone have any ideas or suggestions?

  • A shot into the dark: Check the manual for the blocksize the drive expects and do a test write with exactly a multiple of that size (or tell tar to use that blocksize). – user62916 Jun 23 '14 at 14:28
  • Hi, welcome to unix.SE. I see you had good intentions with your attempts to format your question clearly. However, your implementation was off-target. I've gone through and made some improvements. Click "edit" to see how code blocks should be formatted on Stack Exchange. – drs Jun 23 '14 at 14:34
  • 1
    A web search found forums.opensuse.org/showthread.php/… . Suggested fix is as @yeti said: increase the blocking factor. try sudo tar cvbf 1024 /dev/st0 /vader – Mark Plotnick Jun 23 '14 at 15:20
  • We're going to try using a blocking factor of 1024. Thanks for the suggestions. I'll get the output as soon as I can. – Valerie Jun 23 '14 at 15:29
  • Ping? It is ok now? – user62916 Jun 27 '14 at 18:56

I've mostly seen this with faulty tape drives (to the point of suspecting the tape first and shipping a unit to an analysis lab), however the other commentators are right in that blocksize matters. There are certainly cases where you need to even increase the buffer_kbs parameter of the st module to correctly write to tape.

I don't have a tape drive anymore, but you can use the sg3_utils to query the drive, and one of the fields there IIRC contained block size information.

|improve this answer|||||

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.