From owner-freebsd-questions  Wed Mar 20 12:10:03 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA29662
          for questions-outgoing; Wed, 20 Mar 1996 12:10:03 -0800 (PST)
Received: from who.cdrom.com (who.cdrom.com [204.216.27.3])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA29619
          for <questions@freebsd.org>; Wed, 20 Mar 1996 12:10:00 -0800 (PST)
Received: from croute.com (ishm2.croute.com [199.97.106.1])
          by who.cdrom.com (8.6.12/8.6.11) with SMTP id MAA26414
          for <questions@freebsd.org>; Wed, 20 Mar 1996 12:09:56 -0800
Received: from bldg1.croute.com by croute.com (4.1/SMI-4.1)
	id AA03700; Wed, 20 Mar 96 14:06:41 CST
Received: from COMPUROUTE/SpoolDir by bldg1.croute.com (Mercury 1.13);
    Wed, 20 Mar 96 14:06:13 +600
Received: from SpoolDir by COMPUROUTE (Mercury 1.13); Wed, 20 Mar 96 14:05:49 +600
From: "Larry Dolinar" <LARRYD@bldg1.croute.com>
Organization:  CompuRoute, Inc.
To: Mark Tinguely <tinguely@plains.nodak.edu>
Date:          Wed, 20 Mar 1996 14:05:41 +600 CDT
Mime-Version:  1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject:       Re: more DAT nonsense [2], basically fixed
Cc: questions@freebsd.org
Priority: normal
X-Mailer: Pegasus Mail v3.22
Message-Id: <4243E95826@bldg1.croute.com>
Sender: owner-questions@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

|  From:           Mark Tinguely <tinguely@plains.nodak.edu>
|  Subject:        Re: more DAT nonsense

|  I have a Sony STD-5000 and a Adaptec 1542, I use :
|  
|  # dump 0udsf 61000 10240 /dev/nrst0 /dev/rsd0a
|  
|  maybe the blocksize is giving you the problem. By not setting
|  blocksize, it defaults to 10k.

By using Jean-Marc's Zucconi's <jmz@cabri.obs-besancon.fr> suggestion, I 
was able to determine most of my problem (he says his defaults to 512, 
.5K).  Now it works, seemingly pointing the finger at blocksize 0 as the 
culprit.

In trying to read a tape I had previously made under Solaris 2.4 with the 
same drive, it revealed a blocksize of 1024, 1K.  

# dump tvf /dev/rst0
Tape block size (512) is not a multiple of dump block size (1024)

So I changed it
# mt -f /dev/st0ctl.0 blocksize 1024
# dump tvf /dev/rst0


So I wonder indeed if there is really any particular default: my
original problem seemed to indicate that with blocksize variable (0), 
there is a built-in cutoff in restore (or something else) of 64K.  In 
other words, I can make a tape if 'mt status' says density 0 (default) or 
0x13 (DDS), blocksize 0, but I can't read it.

Unfortunately, I'm unable to "tvf" the Sparc tape, as it errors off with 
st0: block wrong size, 32 blocks residual

Perhaps an indication that the KB per dump record is off/incompatible?  
I'm just guessing, and this portablility issue is not critical: I'd just 
like to be able to TOC a dump tape made off Solaris, not restore it.

I prefer your parameters (same as I used on Sparc20, taken from a Conner 
or Sony tech note).  I'll probably play with this some more to see how 
efficient I can get the tape usage.

Many thanks for the suggestions so far; this list leads where others but 
follow.

best regards,
larry