🚀 go-pugleaf

[This is drifting away from Perl. Followups directed away from
comp.lang.perl.misc. I hope I chose the new groups correctly.]

In article <3vnven$lva@pheidippides.axion.bt.co.uk>,
Bill Parker  <W.Parker@NWH3HP.BTMNS.btmns.btx400.co.uk> wrote:
>My ICL DRS 6000 has a couple of 8mm exabytes attached to it...

>In general, I try to use the (maximum?) 64Kb blocksize when writing to 
>either of 'em. I prefer to use cpio...

>i.e. find ... | cpio -o... -C 65336 > ${TAPE}

>rather than tar, so I'm not sure how block sizes are implemented on tar.

You can use the -b option. By default, the units are blocks of 512 bytes,
but of course you can say "tar cbf 64k $TAPE". Note that by default, most
versions of tar will (recursively) back up all the files in . unless you
give specific file names on the command line. Read the man page for your
version of tar to see if it supports taking the names of files to be dumped
from standard input, or from a temporary file. (But pax, the POSIX replacement
for both tar and cpio, will read the file names from standard input if none
are named on the command line. Incidentally, pax also uses the -b option
to specify blocking: "find ... | pax -w -b 64k -f $TAPE". By default,
pax writes tar files, but you can add "-x cpio" to change that.) 

About 64k as a blocking size for 8mm tape drives, note that

(a) Sun's manual pages (at least under 4.1.x) recommend 63k (126b) instead,
for some reason that is not entirely clear to me at the moment; and

(b) not all implementations of tar are equal. AIX tar, in particular,
won't accept a b or k suffix to the blocksize, and won't accept blocksizes
larger than the default of 20b. So if you want to write or read your tapes
on an AIX system using IBM's own tar, you should not use the larger blocksizes.
(I tested this with AIX tar 1.49.2.8; maybe the problem has gone away since
then. AIX pax doesn't seem to have this limitation, so you can use that
instead.)

>The aim, as you point out, is to try and keep the device streaming, 'cos 
>it's slow enough at the best of times... anyone else got any tips on 
>streaming devices?

That's why I'm including comp.periphs.scsi on this. (8mm drives are
normally attached via SCSI.) 
I vaguely remember reading that if you send the next request to the driver
before the previous transfer has completed, it may be able to stream.
Obviously this depends both on the driver software and on the drive/bus
hardware.
I'm not entirely sure that streaming is as important for 8mm drives as
it is for conventional 9-track tapes (or for newer, fast high-density
tape technologies; DAT and Exabyte are _slow_ high-density technologies).
Isn't the reason 8mm tapes are slow precisely that the hardware is not
designed for fast starting and stopping of the tape motion?
-- 
Sergio Gelato <gelato@sissa.it>