idall@augean.OZ (Ian Dall) (05/05/87)
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 ROM monitor: C 1:0:1 7 It takes about 5 minutes to copy 19 MBytes. Which establishes the speed of the hardware. If I use the volcopy program: 19 MBytes takes 17 minutes. The tape keeps stopping, backing up and starting again. I presume I am not specifying suitable options for volcopy. I don't understand many of the options most of which don't seem applicable to QIC-24 cartridges. I used a blocking factor of 10 (should this be increased?), and in response to the queries specified 2400ft and 8000bpi (which I assume it makes no constructive use of (with these drives) except to see whether your filesystem will fit into one tape or not). 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. 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? Is the rotational gap the same as interleaving (which can be handled by the disk drive) and should the blocks/cylinder be the number of usable blocks (ie excluding bad block replacement) or the number of physical blocks? I used the defaults and it doesn't seem to worry it but could I get better performance by altering them? Perhaps some of these questions belong in unix.wizards which I will try if no one reading this news group can help. Thanks, Ian Dall idall@augean.OZ .
joer@nscpdc.UUCP (05/12/87)
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) * * * ******************************************************************************/