>I measured (cstream(8)) that it needs about 6 Mbs to keep the tape
>streaming.
Does it tell you how it did that? For instance, what block size did
it use? Does it use the normal write() system call? Is the data random
or a fixed pattern? Do you have hardware compression turned on?
>Tape write rate given in Amanda reports is (stable values)
>
>Avg Tp Write Rate (k/s) 4643.2 4687.7 3698.6
You need to split these into dumps that were written to tape from
the holding disk vs. those written directly to tape from the network.
To do that, look at the amdump.<nn> file(s). Those with "FILE-WRITE" are
holding disk -> tape. Those with "PORT-WRITE" are network/dumper -> tape.
The "DONE" line from taper tells you the KBytes/s rate.
The next question is, can the holding disk feed taper fast enough? I
would test it this way (very carefully):
* Create a second configuration just like your main one but with a
separate curinfo, etc.
* Reload a good sized (10's to 100's of MBytes) image from some tape
into the holding disk. Actually, I'd store it in a temp area within
the holding disk, then create the holding disk datestamp directory and
finally hard link the temp file name(s) to the datestamp directory.
That way, when you run amflush below, the file names will be removed
from the datestamp directory but you can quickly re-create it to
adjust some values and try the test again.
For instance:
cd /holding/disk
mkdir xxx
cd xxx
amrestore $TAPE some-host some-disk
dd if=some-host.some-disk.nn bs=32k count=1 # to get the datestamp
cd ..
mkdir YYYYMMDD
ln xxx/* YYYYMMDD/.
To repeat a test, all you have to do is rerun the last two steps
(mkdir and ln).
* dd the image from the holding disk to /dev/null with bs=32k and
see what kind of rate you get.
* Set tapedev in the alternate configuration to /dev/null.
* Run amflush with the alternate configuration and see what kind of
rate you get.
Then I'd try the above test cases with a real tape and see what you get.
Keep in mind that the holding disk may now be contending with the tape
if they are on the same bus. If you have enough disk space on some
other device, you could try putting the holding disk there for testing.
About the only tunable taper has is the number of buffers (tapebufs).
I'd try doubling that and see what happens, but only after I was sure
nothing else was the bottleneck.
>Olivier
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
