Bug 9915 - tar and dd report I/O Error on SCSI Tape while mt seems to work
Summary: tar and dd report I/O Error on SCSI Tape while mt seems to work
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mt-st   
(Show other bugs)
Version: 6.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-03-02 09:22 UTC by weinmann
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-03-16 15:02:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description weinmann 2000-03-02 09:22:28 UTC
We use a SCSI tape (DDS-3) on a Netfinity 5500-M20 running RedHat Linux V
6.1 (German).

Operations like "mt rewind" and "mt erase" seem to work (At least they
report no error and the tape drive is doing something.). But "dd if=xxx
of=/dev/st0 bs=512" comes up with an I/O Error. I tried "dd if=/dev/zero
of=/dev/nst0 bs=512 count=1" and it reported no error which indicates that
it is not a HW problem.

"tar -c -v -b 1 -f /dev/st0 xxx" reports no error. But when I try to read
the tape afterwards with "tar -t -v -b 1 -f /dev/st0" it comes up with
"Doesn't look like a tar archive ... skipping to next file header".

I tried the above commands with different block size but the result was the
same. We have a second Netfinity 5500 (no M20) with the same SCSI tape
drive but running DLD Linux 6.0. And there all these command run without
any problem in production since 1 1/2 year.

Comment 1 weinmann 2000-03-10 14:24:59 UTC
We exchanged the tape with another one from a different vendor but the
behaviour is the same. mt status, mt rewind and mt retension work fine.
But mt setblk xxx, tar and dd report /dev/st0 I/O-Error.

Comment 2 Jeff Johnson 2000-03-10 14:29:59 UTC
All of status/retension/rewind do not read data from the media, while
tar/dd do, so the behavior is consistent.

Are there error messages in /var/log/messages?

Is there *any* tape that can be read by the drive?

Is there any tape that can be *written* by the drive?

Comment 3 weinmann 2000-03-10 14:51:59 UTC
  dd if=xxx of=/dev/st0
/var/log/messages has an entry
  Mar 10 14:50:17 altair kernel: st0: Write not multiple of tape block size.
  Mar 10 14:51:17 altair last message repeated 2 times
I checked with different blocksizes: (bs=0, bs=1, bs=64, bs=512, bs=1024) but it
is all the same.

  tar cfv /dev/st0 xxx
there is no entry in /var/log/messages. But if I issue afterwards
  mt rewind
and then
  tar tfv /dev/st0
the tar command responds with
  tar: Hmm, das sieht nicht wie ein ;tar+-Archiv aus.
  tar: Springe zum Kopfteil der ndchsten Datei.
. Translation: Doesn't look like a tar archive. Jumping to next File.

We tried to write with different tapes (but all same vendor/type). But the
result was the same. We have the same type of tape  also in another Netfinity
5500 (no M20) running DLD Linux and it works fine since nearly 1 1/2 years.

Regarding reading tapes: Though we have a tape device that works in another
Netfinity 5500 I cannot change the backup procedures there and I have no access
to that tape device or the tapes. This server is running in production and I am
not allowed to use it for some test purposes.

Stuff like cabling and termination an external HW support company and myself
already verified.

Comment 4 weinmann 2000-03-16 15:02:59 UTC
We installed an Adaptec SCSI controller in addition and attached the tape
device to it. Now we can work with the tape device.

Though this is a workaround and not a fix it solves our issue to work with the
tape device. So we will not continue to firther investigate and the request is
closed from our side.

Comment 5 Steve Weifenbach 2000-06-06 21:36:52 UTC
I believe the culprit is the ServeRAID driver not handling tape drives.  We 
added a Adaptec SCSI adapter, as well, based on the last posting here.  That
works fine.  The only difference was the adapter/driver.

Hope this helps.

Note You need to log in before you can comment on or make changes to this bug.