🚀 go-pugleaf

In article <168@augean.OZ>, idall@augean.OZ (Ian Dall) writes:

(Original lines edited for brevity sake.)

>Backing up to tape on an ICM 3216 under Unix V.2 using volcopy takes a lot
>longer than it should. If I use the volcopy program:
>The tape keeps stopping, backing up and starting again.

This is because volcopy does not stream.  UNIX writes under volcopy are
blocking, this means that UNIX waits for a reply from the writing device
after each segment of data has been transmitted prior to transmitting the
next segment of data.  Between data segments, the physical tape drive must 
back the tape up to a point prior to the end of the last written data, then, 
moving the tape in a forward direction, come up to speed prior to reaching
that same point.  When the end of data point is reached the write may occur.

The closest approximation of streaming that can be accomplished when using 
volcopy is accomplished by specifying a blocking factor (blocks per write) 
close to the SCSI copy size limitation (127K) of the system.

>I used a blocking factor of 10 (should this be increased?),

Yes, you have requested copy to occur in 5K increments, far from the system
capability.  Optimum performance will be achieved with a blocking factor
of 254.

>and in response to the queries specified 2400ft and 8000bpi (which I assume 
>it makes no constructive use of except to see whether your filesystem
>will fit into one tape or not).

True.  Specification of tape density is accomplished by selection of driver.

>Any one else use volcopy? What options do you use and what performance do you
>get. Perhaps volcopy is not very intelligent and doesn't know that SCSI devices
>can copy between themselves without going through CPU memory -- in which case
>perhaps this is a limitation of Unix (it does seem a bit difficult to see how
>direct device to device copies could fit into Unix's idea of treating devices
>as (special) files). As it stands it would be quicker (though less convenient)
>to halt, use the ROM monitor and reboot. 

UNIX can make no assumptions about the system architecture, (device 
independence), therefore, volcopy knows nothing about the actual data
transference methodology (SCSI in this case).  

>Another question: When one creates a file system, mkfs defaults to 400blks/cyl
>and 8 blk gap. Do these numbers have any significance for an intelligent
>drive (such as scsi) especially when the disk drive has significant (16kB)
>buffers? 

Yes, these numbers are significant, (also, the gap size is 7).  Explanation
follows:

>Is the rotational gap the same as interleaving (which can be handled
>by the disk drive) 

No, "rotational gap" compensates for operating system latency, interleaving
compensates for interface latency, (which, in the case of SCSI, is typically
1:1).

>and should the blocks/cylinder be the number of usable 
>blocks (ie excluding bad block replacement) or the number of physical blocks?

Use usable blocks.  If UNIX knows the number of actual blocks in a cylinder, 
the performance of a system can be optimized.  If all physical references
to a file are within the same cylinder, no head movement is required to
access all blocks within the file.  Head switch time (electronic) is far
faster than head seek time (mechanical).

>I used the defaults and it doesn't seem to worry it but could I get better
>performance by altering them?

This depends upon the physical characteristics of the actual device that you 
are using.  Only experimentation will answer that question for you.  The 
defaults were chosen as good "ballpark" figures to start a system up with.

>Thanks,

You're welcome

-- 
/****************************************************************************** *                                                                             *
*  Joe Rawlings                         nsc!nscpdc!joer         or            * *  ICM Product Support                  tektronix!reed!nscpdc!joer            *
*  National Semiconductor Corp.         1-800-222-2433 (outside Oregon)       * *  Portland Development Center          or    629-4414 (inside Oregon)        *
*                                                                             * ******************************************************************************/