From plm@plm.xs4all.nl  Sun Feb  9 04:46:02 1997
Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA15200
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 9 Feb 1997 04:45:42 -0800 (PST)
Received: from asterix.xs4all.nl (root@asterix.xs4all.nl [194.109.6.11]) by smtp1.xs4all.nl (8.7.6/XS4ALL) with ESMTP id NAA28596 for <FreeBSD-gnats-submit@freebsd.org>; Sun, 9 Feb 1997 13:43:17 +0100 (MET)
Received: from plm.xs4all.nl (uucp@localhost) by asterix.xs4all.nl (8.7.5/8.7.2) with UUCP id NAA20645 for FreeBSD-gnats-submit@freebsd.org; Sun, 9 Feb 1997 13:34:24 +0100 (MET)
Received: (from plm@localhost) by plm.xs4all.nl (8.8.4/8.7.3) id NAA02128; Sun, 9 Feb 1997 13:24:33 +0100 (MET)
Message-Id: <199702091224.NAA02128@plm.xs4all.nl>
Date: Sun, 9 Feb 1997 13:24:33 +0100 (MET)
From: Peter Mutsaers <plm@xs4all.nl>
Reply-To: plm@xs4all.nl
To: FreeBSD-gnats-submit@freebsd.org
Subject: scsi tape driver problem
X-Send-Pr-Version: 3.2

>Number:         2698
>Category:       kern
>Synopsis:       After rewind I cannot read a tape; blocksize problems
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Feb  9 04:50:01 PST 1997
>Closed-Date:    Sun Oct 29 10:29:49 PST 2000
>Last-Modified:  Sun Oct 29 10:30:59 PST 2000
>Originator:     Peter Mutsaers
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
>Environment:

NCR815 SCSI interface, QIC-150 tape (in 525 MB drive)

>Description:

When I've written a dump, and try restore on that dump, I get a read error.

>How-To-Repeat:

$ mt -f /dev/nrst0 status
Present Mode:   Density = QIC-150      Blocksize = 512 bytes
---------available modes---------
Mode 0:         Density = 0x00         Blocksize variable
Mode 1:         Density = X3.136-1986  Blocksize = 512 bytes
Mode 2:         Density = X3.39-1986   Blocksize variable
Mode 3:         Density = X3.54-1986   Blocksize variable
$ dump 1af /dev/rst0 /dev/rsd1f
....
...
$ restore tf /dev/rst0 
tape read error: Input/output error
console output: st0: block wrong size, 64 blocks residual

When I open tapedrive and close it again, I can read with restore t.
But only once. When I try again I get the same error.

Also, I can never read a dump with dd (dd if=/dev/rst0 bs=512 fails):
$ dd bs=512 if=/dev/rst0 of=/dev/null
dd: /dev/rst0: Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 12.830684 secs (0 bytes/sec)

console output: st0: 10240-byte record too big

Although I did specify bs=512!

Note: using tar instead of dump does not cause such problems. So dump
must do something special to the device that triggers the problem.

>Fix:
	
	

>Release-Note:
>Audit-Trail:

From: j@uriah.heep.sax.de (J Wunsch)
To: plm@xs4all.nl
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/2698: scsi tape driver problem
Date: Sun, 9 Feb 1997 14:58:28 +0100

 As Peter Mutsaers wrote:
 
 > NCR815 SCSI interface, QIC-150 tape (in 525 MB drive)
 
 What drive?
 
 > Also, I can never read a dump with dd (dd if=/dev/rst0 bs=512 fails):
 > $ dd bs=512 if=/dev/rst0 of=/dev/null
 > dd: /dev/rst0: Input/output error
 > 0+0 records in
 > 0+0 records out
 > 0 bytes transferred in 12.830684 secs (0 bytes/sec)
 > 
 > console output: st0: 10240-byte record too big
 
 This looks odd.  It means the drive wrote variable-sized records, as
 opposed to fixed-length 512 bytes.  I think this is beyond the specs,
 and this drive is plain broken.  QIC-150 does IMHO only know about
 fixed-length 512-byte blocking.  I bet you can't read these tapes on
 another drive at all.
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)

From: Bill Paul <wpaul@skynet.ctr.columbia.edu>
To: plm@xs4all.nl
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/2698: scsi tape driver problem
Date: Sun, 9 Feb 1997 13:10:30 -0500 (EST)

 Of all the gin joints in all the towns in all the world, Peter Mutsaers 
 had to walk into mine and say:
 
 > $ dump 1af /dev/rst0 /dev/rsd1f
 > ....
 > ...
 > $ restore tf /dev/rst0 
 > tape read error: Input/output error
 > console output: st0: block wrong size, 64 blocks residual
 
 What about if you force a particular block size with dump/restore:
 
 % dump -b 126 1af /dev/nrst0 /dev/rsd1f
 % restore -b 126 ivf /dev/nrst0
  
 > Also, I can never read a dump with dd (dd if=/dev/rst0 bs=512 fails):
 > $ dd bs=512 if=/dev/rst0 of=/dev/null
 > dd: /dev/rst0: Input/output error
 > 0+0 records in
 > 0+0 records out
 > 0 bytes transferred in 12.830684 secs (0 bytes/sec)
 > 
 > console output: st0: 10240-byte record too big
 > 
 > Although I did specify bs=512!
 
 But it's telling you that the dumps were written with 512*20 byte blocks. 
 Try using dd with bs=10240 (or bs=20b, which is equivalent). In order to
 get dump(8) to create a dump volume with 512 byte blocks, you'd have to
 do 'dump -b1' (1*512). I'm pretty sure it doesn't do that by default, so
 trying to read the dump back with dd using a 512 byte block size can't
 possibly work.
  
 > Note: using tar instead of dump does not cause such problems. So dump
 > must do something special to the device that triggers the problem.
 
 Could be dump and restore disagree on their default buffer sizes. Out
 of force of habit, I always explicitly specify a block size with dump
 and restore, except when running them through pipes to stdin/stdout.
 
 -Bill
 
 -- 
 =============================================================================
 -Bill Paul            (212) 854-6020 | System Manager, Master of Unix-Fu
 Work:         wpaul@ctr.columbia.edu | Center for Telecommunications Research
 Home:  wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
 =============================================================================
  "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
 =============================================================================

From: Peter Mutsaers <plm@xs4all.nl>
To: Julian Elischer <julian@whistle.com>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/2698: scsi tape driver problem
Date: Mon, 10 Feb 1997 18:54:10 +0100 (MET)

 >> On Sun, 09 Feb 1997 12:46:23 -0800, Julian Elischer
 >> <julian@whistle.com> said:
 
     JE> Peter Mutsaers wrote:
     JE> try always using nrst0 for all operations.. I never use rst0
 
 In fact I did. Then I did a mt -f /dev/nrst0 rewind and tried to restore.
 
 For the bugreport I tried with /dev/rst0 instead.
 
 It doesn't make a difference.
 
 My tapedrive is not broken. It works without such problems on Linux
 and NT4.0. (Maybe because Linux doesn't treat it as a raw device?)
 
 It is a DEC TZK:
 
 st0 at scbus0 target 2 lun 0
 st0: <DEC TZK10 00B3> type 1 removable SCSI 2
 st0: Sequential-Access 
 st0: asynchronous.
 density code 0x0,  drive empty
 
 This is exactly the same as a Wangtek 525MB drive, I think the Wangtek
 5525 ES.
 
 Could/should I tell the driver that it is a Wangtek? The handbook
 says:
 
 This drives quirks are known and pre-compiled into the scsi tape device driver
 (st(4)).
 
 
 -- 
 Peter Mutsaers  |  Abcoude (Utrecht), |  Trust is a good quality
 plm@xs4all.nl   |  the Netherlands    |  for other people to have
State-Changed-From-To: open->closed 
State-Changed-By: mjacob 
State-Changed-When: Sun Oct 29 10:29:49 PST 2000 
State-Changed-Why:  
Old bug- and in this was, in fact, pilot error as they weren't using 
the right minor to match the fixed blocksize. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=2698 
>Unformatted:
