On Mon, Oct 14, 2002 at 10:20:18AM +0200, jordivi wrote:
> Hi
>
> My backups fails using soft compression on large disks, using
> tar or dump + gzip I get things like:
> -------------------------------------------------------------------
> FAILURE AND STRANGE DUMP SUMMARY:
> server1 /disk1 lev 0 FAILED [input: Can't read data: : Connection
> timed out]
> server1 /disk1 lev 0 FAILED [dump to tape failed]
>
> Or:
>
> sendbackup: time 890.002: 115: strange(?): sendbackup: index tee cannot
> write [Connection reset by peer]
> sendbackup: time 890.002: index tee cannot write [Connection reset by
> peer]
> sendbackup: time 890.024: pid 22390 finish time Sun Oct 13 15:43:39 2002
> sendbackup: time 890.026: 91: normal(|): DUMP: Broken pipe
>
> Or:
>
> "dumper 0 is messed up, ignoring it"
> ps -fea -> dumper <defunct>
> -------------------------------------------------------------------------
Have you tried increasing your timeout settings in amanda.conf.
I have one system that takes so long (damn M$!!) I had to triple
or quadruple mine.
> So I'm thinking on work without compression (what works fine) and turn
> hw compression on with a bogus tapetype definition. I have:
> # HP Model: C5683A Rev: C104
> # HP DD-4 40Gb data cartridge C5718A
> # HP SureStore DAT40i C5683A. No hw compress. Media DDS4 150m HP-C5718A
> define tapetype DAT40i {
> length 19488 mbytes
> filemark 538 kbytes
> speed 3073 kbytes
> }
>
> Is ok to turn hw compression on and define a tape length about 1.8*19488
> mbytes? filemark and speed should remain to de above values?
Many do. Your speed will probably be much higher as it is generally limited
by how fast bits, hw compressed or not, are able to be put on the tape.
Yet it is expressed in terms of how fast data goes to the drive, not to the
tape.
Your fudge factor, 1.8, can only be locally guessed. You could get some
idea of your local compressibility of disklist entries by looking in
the curinfo directory. Here is a sample of just one of my many entries
version: 0
command: 0
full-rate: 872.000000 758.000000 1124.000000
full-comp: 0.365849 0.365735 0.365641
incr-rate: 40.000000 303.000000 64.000000
incr-comp: 0.199308 0.348489 0.254122
stats: 0 2989910 1093856 1253 1034215630 15 DS1-03
stats: 1 204770 71360 235 1034409820 14 DS1-06
stats: 2 17340 3456 86 1034582638
last_level: 2 1
The things you want to check are "full-comp", the last 3 compression
rates for level 0, full, dumps. If all my data were like this entry
a 1.8 fudge factor would be very conservative, over 2.5 would be
more appropriate.
Unfortuanately not all my file systems are like this one. Some give
compression rates of 0.98, i.e. not compressible at all.
Next you have to worry about amount of data. Under "stats: 0" is the
total data size and compressed data size of the most recent level 0
for that disklist entry (in KB).
Just for fun I grep'ed all my "info" files for the stats: 0 line and
summed up the total and compressed data columns. I got 71.4 GB and
51.2 GB. That is a compression rate overall of 0.717, or a fudge
factor of 1.39. Your 1.8 would have been wildly optimistic for
my data. Even though it would have been wildly conservative for
the one file system data shown above.
That's why fudge factors are called that, fudge. It is a sticky problem.
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
