Gerhard den Hollander wrote at 12:01 +0200 on Sep 19:
> * John E Hein <[EMAIL PROTECTED]> (Tue, Sep 18, 2001 at 09:32:57AM -0600)
> > Hmmm... it also seems to not take compression into account (we use gnu
> > tar with client side compression). The estimated size is much larger
> > than the actual size. amstatus gives:
>
> No, it doesn;'t take compression into account , neither does ufsdump or
> gnutar .. at least the way I have it setup.
okay... I'll buy that for the moment.
> Amanda keeps track of the compression ratios and uses those to get a
> correct(er) estimate from the estimate returned by the estimate program.
> e.g.:
> hyperion:/volume/amanda/reports/mammoth1/curinfo/hyperion/sdb2 # less info
> version: 0
> command: 0
> full-rate: 648.000000 53.000000
> full-comp: 0.496944 0.004881
> incr-rate: 992.000000 992.000000 992.000000
> incr-comp: 0.987065 0.987065 0.987065
> stats: 0 984320 489152 754 1000836653 11 MAM0125
> last_level: 0 1
> //
>
>
> Are you by any chance runnign some form of tar where the tar command does
> the compression ?
> (like tar -z or tar -j )
Not to my knowledge. The only thing we changed was to drop in your patched
sendsize compiled with -DUSE_GENERIC_CALCSIZE. Everything else remained
the same. Here's the dumptype we use (some disklist entries use a lower
priority, but are otherwise the same):
define dumptype comp-high-tar {
comment "high priority partitions dumped with tar"
index yes
program "GNUTAR"
priority high
compress client fast
}
> > So for our 12 GB DDS-3 drive, we're getting a lot of 'full dump delayed'
> > messages because of this issue.
>
> If you know this, you can specify the tapesize to be 24G (iso 12G) and you
> should get the dumps you think you were getting.
I suppose, but why do we need to do that now where we didn't before (when
we were using gnu tar for estimates)?
Last night things got even worse. It only used 1.8 GB of the tape and
we got 24 'full dump delayed' messages (the night before was 13 such
messages and it used 5 GB).
STATISTICS:
Total Full Daily
-------- -------- --------
Estimate Time (hrs:min) 1:55
Run Time (hrs:min) 3:48
Dump Time (hrs:min) 9:19 0:55 8:24
Output Size (meg) 1883.8 1093.2 790.6
Original Size (meg) 6552.6 3346.6 3206.0
Avg Compressed Size (%) 28.7 32.7 24.6 (level:#disks ...)
Filesystems Dumped 86 8 78 (1:64 2:10 3:3 4:1)
Avg Dump Rate (k/s) 57.5 339.6 26.8
Tape Time (hrs:min) 0:34 0:17 0:17
Tape Size (meg) 1886.5 1093.5 793.0
Tape Used (%) 16.2 9.4 6.8 (level:#disks ...)
Filesystems Taped 86 8 78 (1:64 2:10 3:3 4:1)
Avg Tp Write Rate (k/s) 951.1 1128.3 781.7
SUMMARY part real estimated
size size
partition : 87
estimated : 87 59411316k
failed : 1 47461212k ( 79.89%)
wait for dumping: 0 0k ( 0.00%)
dumping to tape : 0 0k ( 0.00%)
dumping : 0 0k 0k ( 0.00%) ( 0.00%)
dumped : 86 1928992k 11950104k ( 16.14%) ( 3.25%)
wait for writing: 0 0k 0k ( 0.00%) ( 0.00%)
The new 'sendsize' is definitely doing something different that is
causing this. Any ideas?
Here's the sendsize.debug from one of the backup clients:
sendsize: debug 1 pid 28646 ruid 5001 euid 5001 start time Wed Sep 19 00:01:02 2001
/site/dist/amanda-2.4.2-20000926/libexec/sendsize: version 2.4.2
calculating for amname 'da0s1a', dirname '/'
calcsize: running cmd: calcsize GNUTAR da0s1a / 0 0 1 1000376322
calculating for amname 'da0s1f', dirname '/home'
calcsize: running cmd: calcsize GNUTAR da0s1f /home 0 0 1 1000455423
calculating for amname 'da0s1g', dirname '/u2'
calcsize: running cmd: calcsize GNUTAR da0s1g /u2 0 0 1 1000288459
calculating for amname 'da0s1e', dirname '/usr'
calcsize: running cmd: calcsize GNUTAR da0s1e /usr 0 0 1 1000456096
calculating for amname 'da0s1d', dirname '/usr/obj'
calcsize: running cmd: calcsize GNUTAR da0s1d /usr/obj 0 0 1 1000457245
calculating for amname 'da0s1h', dirname '/usr/src'
calcsize: running cmd: calcsize GNUTAR da0s1h /usr/src 0 0 1 1000800006
sendsize: pid 28646 finish time Wed Sep 19 00:02:22 2001
Here's what amstatus showed for these filesystems.
bugs:da0s1a 1 320k finished (2:18:12)
bugs:da0s1d 1 160k finished (1:56:40)
bugs:da0s1e 1 256k finished (2:10:06)
bugs:da0s1f 0 2112k finished (2:18:43)
bugs:da0s1g 0 61952k finished (2:05:25)
bugs:da0s1h 1 32k finished (1:55:51)
This client is one of the very few that had partitions for which a level
0 dump was performed. But those are very small file systems. All of
the large file systems are being delayed for level 0 dumps.
