On Wednesday 25 September 2002 01:46, Martin Schwarz wrote:
>On Sun, Sep 22, 2002 at 10:44:35AM +0200, Martin Schwarz wrote:
>> On Sat, Sep 21, 2002 at 04:00:31PM -0400, Gene Heskett wrote:
>> > The above looks as if you have the drives compression turned
>> > on,
>>
>> I have, although I should know better about this - having read
>> the list for a while. Somehow I never thought about my own setup
>> when reading about the cons of hardware compression... will
>> switch it off.
>
>Hardware compression is now switched off (both with the drive's
> internal dip switch and the mt utility option), and I have rerun
> tapetype after making sure the tape's internal information on
> this was cleared (following Gene's instructions - thanks!). The
> results are as follows (this is a WangDAT 3400DX SCSI DAT drive
> with a DDS2 120m tape):
>
>----------------------------------------------------------------
>martin@lissy:~$ sudo -u backup tapetype -h
>usage: tapetype -h [-e estsize] [-f tapedev] [-t typename]
> -h display this message
> -e estsize estimated tape size (default: 1g == 1024m)
> -f tapedev tape device name (default: $TAPE)
> -t typename tapetype name (default: unknown-tapetype)
>
>Note: disable hardware compression when running this program.
>martin@lissy:~$ time sudo -u backup tapetype -e 4g -t DDS2-120m &&
> echo done.
>wrote 121830 32Kb blocks in 93 files in 11355 seconds (short
> write) wrote 111350 32Kb blocks in 170 files in 11570 seconds
> (short write) define tapetype DDS2-120m {
> comment "just produced by tapetype program"
> length 4202 mbytes
> filemark 4355 kbytes
> speed 325 kps
>}
>
>real 384m37.786s
>user 0m1.980s
>sys 4m6.670s
>done.
>martin@lissy:~$
>----------------------------------------------------------------
>
>I'm not sure if this is correct.
>
>- The length value looks good. How was that influenced by the
> estimate of 4GByte I gave with the -e option? I had left out this
> option the last time I ran tapetype.
Having the estimate available means that tapetype can have a go at
it in pieces sized somewhat for the tape, rather than doing
itty-bitty blocks by the hundreds of thousands on pass one. That
makes the run take a bit less time since it doesn't have to play
blind man feeling his way along with a cane so to speak.
>- The filemark seems to be unusually high. Can this be correct?
Probably. But I don't think that its size, but rather how far apart
they are on the tape. Somebody please correct me if that
assumption on my part is wrong. When and if you re-run tapetype
again, leave out or change the -e option and see if that effects
the filemark value returned. But it will take longer to run
without the -e option IIRC.
> Does this mean I'm wasting over 4 MBytes between two files on
> tape? Is this something that can be changed or is it a property
> of the drive?
I'm not aware of a method to change this, but someone here might
know, in which case they should speak up.
> - The speed is not that high, but might well be
> correct. The machine the tape drive is connected to is a lowly
> Pentium-133...
The drive can do about 350-375 on hot rod machines, so its possible
the p133 is beginning to effect it somewhat. I certainly wouldn't
want to run the compression on that machine as I'd think that a
dumptype spec of "compress server best" would be downright painfull
to watch, if you could manage to stay awake. :-) Besides, compress
client best also means there are fewer bytes to ship over the
network, and several clients can be crunching data simultainiously,
both of which will speed things up by large amounts.
>I will try to rerun the tapetype utility on another tape and see
> if the results are similar.
>
>Thanks for your time and your comments!
>Martin.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.16% setiathome rank, not too shabby for a WV hillbilly
|
