In an attempt to reduce "shoe shining" (before I tried setting ft_fdc_rate_limit a
little
lower), I tried setting one of my backup commands as follows:
...
declare -i FTAPE_BLOCK_SIZE=10240
declare -i MULTI_BLOCK=4 <---<<<
declare -i IO_SIZE
IO_SIZE=FTAPE_BLOCK_SIZE*MULTI_BLOCK
...
cat $WHERE | cpio -o -a --io-size=$IO_SIZE --format=crc -O $OUTPUT_DEVICE
...
(part of a cron-related bash script file that does backups; $WHERE is a file containing
the names of the files to back up)
It is my understanding (perhaps mistaken) that the --io-size parameter to cpio must be
a
multiple of 10240 for this drive. But I am unclear if making it larger will help.
Someone
(Tim Jones?) in the Ftape-FAQ suggested suggested
afio -o -v -f -b 10240 -c 800 /dev/qft0
I know nothing about afio, but from that, I infer that cpio would do the same thing if
I
set MULTI_BLOCK (above) to 800, though I have not tried that. There seems to be a
problem
with that to me. I doubt the driver allocates buffers any where near 10240 x 800 bytes
each. So there would be a big pause each time it finishes up one of those things from
cpio
and cpio reads the next batch.
My guess is to use enough --io-size so that cpio can refill the buffer before ftape
needs
another set of input, but to not go a lot further than that.
Can anyone help me understand what is really going on enough for me to set a good value
for --io-size for cpio?
--
Windows is not the answer. Windows is the question. The answer is no.
Jean-David Beyer
Shrewsbury, New Jersey