Xref: utzoo comp.periphs:3471 comp.sys.sgi:8302 comp.periphs.scsi:1902
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!brunix!sgf
From: sgf@cs.brown.edu (Sam Fulcomer)
Newsgroups: comp.periphs,comp.sys.sgi,comp.periphs.scsi
Subject: Re: exabyte record size limit
Message-ID: <65123@brunix.UUCP>
Date: 15 Feb 91 15:19:38 GMT
References: <1991Feb8.152435.10875@helios.physics.utoronto.ca> <1991Feb14.223941.4318@b11.ingr.com>
Sender: news@brunix.UUCP
Reply-To: sgf@cfm.brown.edu (Sam Fulcomer)
Organization: Brown University Center for Fluid Mechanics
Lines: 35

In article <1991Feb14.223941.4318@b11.ingr.com> mcconnel@b11.UUCP (Guy McConnell) writes:
>
>   The Exabyte does not seperate physical records unless they are in different
>save-sets.  At the end of a write operation the drive writes a "gap track" 

	This is true after a tape controller write operation, but not 
	necessarily true after the driver-level write (ie, the scsi CDB and 
	data transfer).  If the drive is operating in buffered mode it will 
	not write until the buffer content reaches the tape movement threshold
	(or until the electronics are taken out of write mode by some other 
	operation) and will then continue to write as much data as it has 
	in its buffer, which may contain many user-blocks (ie, the controller
	write operation continues until the buffer is empty, without gap
	blocks or tracks, regardless of the characteristics of the user-block). 

>end.  I still got 2.3Gb of data on the tape.  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".  Multiply this

	See my comments above. This is not the documented operation of my 
	8200 units, and I haven't been surprised by empirical evidence.
	Buffered mode and 1k-multiple block size appear to be the only
	important parameters. Since an intelligently designed driver would 
	default to buffered mode for any tape device that can handle it,
	most people would only need to worry about the 1k-multiple block size
	(eg, SGI and Sun users...).

	This whole thing is getting a bit tedious. If anyone has any 
	contradicting comments let's continue via e-mail until a 
	consensus can be posted.