Hi,
I have a Seagate STT20000A IDE tape drive, which I am trying to use
with the ide-scsi driver. It worked well enough when moving data
around to repartition recently, but I have discovered a repeatable
problem.
If I try and save a tar to the tape twice in succession, rewinding and
reading forward to the same point each time first, the second attempt
fails (details below).
I originally found this under 2.2.19, and upgraded to 2.4.13 to see if
the problem was still there when running more recent code. It is.
Here is a script which demonstrates the problem for me:
#! /bin/sh
set -e
TAPE=/dev/nst0
hsize=512
set -x
mt -f $TAPE rewind
echo "tape 1" | dd conv=sync of=$TAPE bs=$hsize count=1
for x in 1 2 3; do
mt -f $TAPE rewind
dd if=$TAPE of=/dev/null bs=$hsize
date
tar -c -b 20 -f $TAPE /boot
done
Here's what the output looks like:
sfere# ./t
+ mt -f /dev/nst0 rewind
+ dd conv=sync of=/dev/nst0 bs=512 count=1
+ echo 'tape 1'
0+1 records in
1+0 records out
+ mt -f /dev/nst0 rewind
+ dd if=/dev/nst0 of=/dev/null bs=512
1+0 records in
1+0 records out
+ date
Tue Oct 30 23:15:01 GMT 2001
+ tar -c -b 20 -f /dev/nst0 /boot
tar: Removing leading `/' from absolute path names in the archive
+ mt -f /dev/nst0 rewind
+ dd if=/dev/nst0 of=/dev/null bs=512
1+0 records in
1+0 records out
+ date
Tue Oct 30 23:15:36 GMT 2001
+ tar -c -b 20 -f /dev/nst0 /boot
tar: Removing leading `/' from absolute path names in the archive
tar: Cannot write to /dev/nst0: I/O error
tar: Error is not recoverable: exiting now
The behaviour is extremely consistent - the second invocation of tar
always fails.
I rebuilt st.o and ide-scsi.o with the debugging macros enabled. The
resulting kernel output is 80Kb long, and rather than fill everyone's
inboxes I've put it at:
ftp://ftp.chiark.greenend.org.uk/users/richardk/tapelog.txt
Some possibly-relevant version numbers:
sfere# uname -a
Linux sfere 2.4.13 #1 Sun Oct 28 12:13:17 GMT 2001 i586 unknown
sfere# tar --version
tar (GNU tar) 1.12
Copyright (C) 1988, 92, 93, 94, 95, 96, 97 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by John Gilmore and Jay Fenlason.
sfere# mt --version
GNU mt version 2.4.2
ttfn/rjk
> I originally found this under 2.2.19, and upgraded to 2.4.13 to see if
> the problem was still there when running more recent code. It is.
> mt -f $TAPE rewind
> echo "tape 1" | dd conv=sync of=$TAPE bs=$hsize count=1
>
> for x in 1 2 3; do
> mt -f $TAPE rewind
> dd if=$TAPE of=/dev/null bs=$hsize
> date
> tar -c -b 20 -f $TAPE /boot
> done
Try "mt fsf" instead dd, see if that helps.
-- Pete
Pete Zaitcev wrote:
>
> > I originally found this under 2.2.19, and upgraded to 2.4.13 to see if
> > the problem was still there when running more recent code. It is.
>
> > mt -f $TAPE rewind
> > echo "tape 1" | dd conv=sync of=$TAPE bs=$hsize count=1
> >
> > for x in 1 2 3; do
> > mt -f $TAPE rewind
> > dd if=$TAPE of=/dev/null bs=$hsize
> > date
> > tar -c -b 20 -f $TAPE /boot
> > done
>
> Try "mt fsf" instead dd, see if that helps.
>
> -- Pete
dd is not guaranteed toposition you beyond the filemark after the first
record. You have to be positioned beyond the filemark to start writing.
Pete's suggestion is a good one. "mt fsf" will position the tape beyond
the filemark and writing to the tape should work at that point.
--
Khalid
====================================================================
Khalid Aziz Linux Systems Operation R&D
(970)898-9214 Hewlett-Packard
[email protected] Fort Collins, CO
> If I try and save a tar to the tape twice in succession, rewinding and
> reading forward to the same point each time first, the second attempt
> fails (details below).
I use 'dd if=<file> of=/dev/nst0 bs=512 conv=sync' all the time to move
dumps from disk to tape w no problems. Differences: 'mt tell' with 'mt seek'
for positioning and only dd for I/O, no tar. Weird.
...
kernel: scsi0 : SCSI host adapter emulation for IDE ATAPI devices
kernel: scsi : 1 host.
kernel: Vendor: HP Model: COLORADO 20GB Rev: 4.01
kernel: Type: Sequential-Access ANSI SCSI revision: 02
kernel: Detected scsi tape st0 at scsi0, channel 0, id 0, lun 0
kernel: scsi : detected 1 SCSI generic 1 SCSI tape total.
...
kernel: st0: Error with sense data: Info fld=0xf000, Deferred st09:00: sns = f1 3
kernel: ASC=50 ASCQ= 1
kernel: Raw sense data:0xf1 0x00 0x03 0x00 0x00 0xf0 0x00 0x10 0x00 0x00 0x00 0x00
0x50 0x01 0x00 0x00
kernel: st0: Error with sense data: Info fld=0xf000, Current st09:00: sns = f0 3
kernel: ASC=50 ASCQ= 1
kernel: Raw sense data:0xf0 0x00 0x03 0x00 0x00 0xf0 0x00 0x10 0x00 0x00 0x00 0x00
0x50 0x01 0x00 0x00
kernel: st0: Error on write filemark.
...
[tim@dell]> tar --version | head -1
tar (GNU tar) 1.13.17
[tim@dell]> mt -v
mt-st v. 0.5b
[tim@dell]> dd --version | head -1
dd (GNU fileutils) 4.0p
[tim@dell]> cat /proc/version
Linux version 2.2.20pre6 (root@abit) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2
release)) #4 Sun Oct 28 22:32:11 PST 2001
rgds,
tim.
--
Khalid Aziz writes:
> Pete Zaitcev wrote:
>> Try "mt fsf" instead dd, see if that helps.
>
> dd is not guaranteed toposition you beyond the filemark after the
> first record. You have to be positioned beyond the filemark to start
> writing. Pete's suggestion is a good one. "mt fsf" will position
> the tape beyond the filemark and writing to the tape should work at
> that point.
Thankyou for the suggestions. However, mt reports that the tape is
positioned beyond the filemark before the failed write. Using "mt
fsf" doesn't make any difference - the problem still occurs.
sfere# cat t
#! /bin/sh
set -e
TAPE=/dev/nst0
hsize=512
set -x
mt -f $TAPE rewind
echo "tape 1" | dd conv=sync of=$TAPE bs=$hsize count=1
for x in 1 2 3; do
mt -f $TAPE rewind
dd if=$TAPE of=/dev/null bs=$hsize
date
mt -f $TAPE status
tar -c -b 20 -f $TAPE /boot
done
sfere# ./t
+ mt -f /dev/nst0 rewind
+ echo 'tape 1'
+ dd conv=sync of=/dev/nst0 bs=512 count=1
0+1 records in
1+0 records out
+ mt -f /dev/nst0 rewind
+ dd if=/dev/nst0 of=/dev/null bs=512
1+0 records in
1+0 records out
+ date
Wed Oct 31 09:06:24 GMT 2001
+ mt -f /dev/nst0 status
drive type = Generic SCSI-2 tape
drive status = 1191182848
sense key error = 0
residue count = 0
file number = 1
block number = 0
Tape block size 512 bytes. Density code 0x47 (unknown).
Soft error count since last status=0
General status bits on (81010000):
EOF ONLINE IM_REP_EN
+ tar -c -b 20 -f /dev/nst0 /boot
tar: Removing leading `/' from absolute path names in the archive
+ mt -f /dev/nst0 rewind
+ dd if=/dev/nst0 of=/dev/null bs=512
1+0 records in
1+0 records out
+ date
Wed Oct 31 09:06:59 GMT 2001
+ mt -f /dev/nst0 status
drive type = Generic SCSI-2 tape
drive status = 1191182848
sense key error = 0
residue count = 0
file number = 1
block number = 0
Tape block size 512 bytes. Density code 0x47 (unknown).
Soft error count since last status=0
General status bits on (81010000):
EOF ONLINE IM_REP_EN
+ tar -c -b 20 -f /dev/nst0 /boot
tar: Removing leading `/' from absolute path names in the archive
tar: Cannot write to /dev/nst0: I/O error
tar: Error is not recoverable: exiting now
sfere# cat ./t
#! /bin/sh
set -e
TAPE=/dev/nst0
hsize=512
set -x
mt -f $TAPE rewind
echo "tape 1" | dd conv=sync of=$TAPE bs=$hsize count=1
for x in 1 2 3; do
mt -f $TAPE rewind
# dd if=$TAPE of=/dev/null bs=$hsize
mt -f $TAPE fsf
date
mt -f $TAPE status
tar -c -b 20 -f $TAPE /boot
done
sfere# ./t
+ mt -f /dev/nst0 rewind
+ echo 'tape 1'
+ dd conv=sync of=/dev/nst0 bs=512 count=1
0+1 records in
1+0 records out
+ mt -f /dev/nst0 rewind
+ mt -f /dev/nst0 fsf
+ date
Wed Oct 31 09:14:16 GMT 2001
+ mt -f /dev/nst0 status
drive type = Generic SCSI-2 tape
drive status = 1191182848
sense key error = 0
residue count = 0
file number = 1
block number = 0
Tape block size 512 bytes. Density code 0x47 (unknown).
Soft error count since last status=0
General status bits on (81010000):
EOF ONLINE IM_REP_EN
+ tar -c -b 20 -f /dev/nst0 /boot
tar: Removing leading `/' from absolute path names in the archive
+ mt -f /dev/nst0 rewind
+ mt -f /dev/nst0 fsf
+ date
Wed Oct 31 09:14:52 GMT 2001
+ mt -f /dev/nst0 status
drive type = Generic SCSI-2 tape
drive status = 1191182848
sense key error = 0
residue count = 0
file number = 1
block number = 0
Tape block size 512 bytes. Density code 0x47 (unknown).
Soft error count since last status=0
General status bits on (81010000):
EOF ONLINE IM_REP_EN
+ tar -c -b 20 -f /dev/nst0 /boot
tar: Removing leading `/' from absolute path names in the archive
tar: Cannot write to /dev/nst0: I/O error
tar: Error is not recoverable: exiting now
sfere#
ttfn/rjk
On Tue, 30 Oct 2001, Richard Kettlewell wrote:
> Hi,
>
> I have a Seagate STT20000A IDE tape drive, which I am trying to use
> with the ide-scsi driver. It worked well enough when moving data
> around to repartition recently, but I have discovered a repeatable
> problem.
>
> If I try and save a tar to the tape twice in succession, rewinding and
> reading forward to the same point each time first, the second attempt
> fails (details below).
[details cut]
Looking at your log everything seems to work perfectly from the point of
view of the drivers. The problem is that the first write command (from the
log cmd: a 1 0 0 3c 0 Len: 30720) is refused by your drive (the sense key
Illegal Request). The command looks OK (i.e., it is a write of 60 512 byte
blocks in fixed block mode).
Does your drive only accept writes from the beginning of the tape (there
are drives that have this limitation)? In this case the problem is that
you rewind and space forward between the two tar commands. You don't have
to rewind between the commands. The same result is obtained if you just
use two consecutive tar commands (and this means that writing only starts
from the beginning of the tape, from the drive's point of view).
Kai
Kai Makisara writes:
> Looking at your log everything seems to work perfectly from the
> point of view of the drivers. The problem is that the first write
> command (from the log cmd: a 1 0 0 3c 0 Len: 30720) is refused by
> your drive (the sense key Illegal Request). The command looks OK
> (i.e., it is a write of 60 512 byte blocks in fixed block mode).
OK...
> Does your drive only accept writes from the beginning of the tape
> (there are drives that have this limitation)?
The manual doesn't mention any such limitation, but it's not very
comprehensive. Suggestions how I can find out whether the drive is
supposed to support arbitrarily positioned writes or not would be
welcome.
> In this case the problem is that you rewind and space forward
> between the two tar commands. You don't have to rewind between the
> commands. The same result is obtained if you just use two
> consecutive tar commands (and this means that writing only starts
> from the beginning of the tape, from the drive's point of view).
This points to an acceptable workaround.
Thanks for your help!
ttfn/rjk
> > I have a Seagate STT20000A IDE tape drive, which I am trying to use
> Does your drive only accept writes from the beginning of the tape
> Kai
I thought that was the property of helical technologies such
as DAT and 8mm. STT20000 must be QIC which ought to work,
that's why I did not bring it up. I saw the Illegal Request too.
Historically ide-scsi worked better with tapes than ide-tape,
so I am puzzled why it fails that way.
-- Pete