exabyte record size limit

[Dave Olson]

In <1991Feb14.223941.4318 at b11.ingr.com> mcconnel at b11.ingr.com (Guy McConnell) writes:

...
| Far more important is the use of
| a blocking factor that is an even multiple of 8192.  Because of the way the
| drive writes data on the tape, if you use something other than a product of
| 8K, you lose capacity.  Each helical track on the tape contains eight 1024 
| byte *physical* blocks of user data.  The minimum writable unit for the drive
| is one track.  Therefore, if you use a block size of, say, 10240, you'll get 
| a logical block containing one track with 8K (8 1K blocks) of user data and
| one track containing 2K of user data and 6K of "gap blocks".

This is not correct, according to the tech people I have talked to
at Exabyte, and the manual.  The only time the padding to 8K
occurs is when you can't keep enough data in the buffer.  If
the drive is writing, and there is not enough data to fill out
a track (8K), then, and only then, will it pad the track out.

A special case of this, is of course, the last write before a FM
or rewind.

If course, if your application is doing some kind of logging, and
is doing intermittent writes of fairly small size, then it is
probably a good idea to do your writes as a multiple of 8K, even
if this means adding soe buffering to the app.

Note that the multiple of 1K issue (padding to 1K at end of
each logical block, if not a multiple) applies whether in
fixed or variable block mode, and is independent of the 8K
track padding.

--

	Dave Olson

Life would be so much easier if we could just look at the source code.