Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!sun-spots-request
From: sgf@cfm.brown.edu
Newsgroups: comp.sys.sun
Subject: Re: Exabyte tape format...
Keywords: Miscellaneous
Message-ID: <5025@brazos.Rice.edu>
Date: 15 Feb 90 16:23:52 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 27
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n20, Replies: v9n38 v9n40 vn41
X-Sun-Spots-Digest: Volume 9, Issue 45, message 3

(and dump parameters...)

All one has to do to get maximum tape utilization out of an Exabyte is to
feed it at least 246kB/sec. Nothing else matters. The Exabyte writes
diagonal stripes (or "tracks") of data that contain up to 8 fixed length
blocks (that can hold up to 1024 bytes user data. If it has only 1k of
data at the time it starts to write out the stripe 1k is all that the
stripe is going to hold.  It marks the rest as an invisible (to the user)
gap. If it doesn't get more data meanwhile it marks the next entire stripe
as another gap and repositions so that when it gets fed it can continue
writing on the stripe following the gap-stripe.

One more time:

It doesn't matter what blocking factor you use in dump. The Exabyte
doesn't write variable-length records. If you can keep data in its buffer
you make the most efficient use of tape (ah, can you say stream? I knew
you could...). The only consideration might be making the block size a
multiple of the 63kB i/o buffer size (used by physio() in the kernel), but
only in extreme conditions might even that make a difference. If you
>>really<< want to save tape do your dumps to disk and then tar them onto
the Exabyte as one big file. sheesh... 

As for density and tape length, who cares? Just pick some big numbers.  (I
apologize to anyone who does multi-tape dumps, hmmm?) The reason one might
worry about it would be to tell dump how much tape it had left so that it
could continue on another, but at $5.88/tape I'd rather not.