On Thursday 21 November 2002 00:47, Gene Heskett wrote:
>On Wednesday 20 November 2002 22:41, Gene Heskett wrote:
>
>Yeah, I know, I'm talking to myself :-) In some circles, thats
>considered to be 'poor form'. But, see below.
Continued, with another "ps:"
>>On Wednesday 20 November 2002 17:36, Jean-Louis Martineau wrote:
>>>On Wed, Nov 20, 2002 at 01:47:50PM -0600, Deb Baddorf wrote:
>>>> What kind of optimiaztion does amanda use while flushing
>>>> dumps to tape?
>>>>
>>>> While doing the dump initially, she seems to
>>>> optimize to get the small jobs done first, and thus they
>>>> go onto tape in a similar order. But I'm currently without
>>>> a stacker. So only the first part of the dumps make it
>>>> to tape "live" (so to speak) and the rest get flushed as I
>>>> manually mount tapes. I'm hoping that some kind of
>>>> knapsack-packing algorithm is used ..... to fit the largest
>>>> files on the tape first, but then to add smaller ones to
>>>> fill the top of the "sack".
>>>> My archival "do all the level 0's" is taking up 5 tapes,
>>>> hence the optimization question!
>>>
>>>There is no optimazation, first in, first out.
>>>That's a need feature.
>>>
>>>Jean-Louis
>>
>>Humm, from a recent example/amanda.conf:
>>-------------
>>dumporder "sssS" # specify the priority order of each
>> dumper # s -> smallest size
>> # S -> biggest size
>> # t -> smallest time
>> # T -> biggest time
>> # b -> smallest bandwitdh
>> # B -> biggest bandwitdh
>> # try "BTBTBTBTBTBT" if you are not
>> holding # disk constrained
>>------------
>>I'm assuming that when Deb asked about it, using the word
>>'flushing', that Deb meant a normal amdump run as opposed to a
>> run of amflush, or an autoflush. I've no idea whether its
>> active for a flush, or just an amdump run. I have no idea if it
>> even works, but I'll find out tonight if I can stay awake till
>> then. I just modified mine to do the biggest ones first, and
>> amstatus should be able to see if its working that way pretty
>> shortly after the estimates are done.
>
>Yes, its working according to an 'SSSsss' setting from the looks
> of it, it started with /usr/src, nearly the last entry in the
> disklist which is nearly 2.7 gigs ATM. It also tells me its
> going to skip 2 entries tonight as they are too big, 1.6gb of
> music and 90 megs of /usr/X11R6 will get delayed till tomorrow
> night. Obviously I'm just now getting amanda restarted after a
> disk crash. I suppose it will take a week to get back to
> 'normal', whatever that is...
Ok, it appears that with the compression being done in software, it
smunched that 2.6 gigs worth of /usr/src down to 1.6 gigs. By the
time it was done, it had written only 2.6 gigs in real data down
the cable to the tape. There was I believe, room enough to fit the
original, uncompressed 1.6 gigs worth of music, and certainly room
enough for a compressed rendition of the 90 megs worth of
/usr/X11R6.
Since at the estmate phase, it hasn't compressed anything, is it
permissable to expand the value tapetype returns in order to
prevent this erronious FAILED message? And if so, do we believe
the vendors propaganda and arbitrarily double it? Or does amanda
do something similar internally? Here is why I ask, from the
email:
----------------------
STATISTICS:
Total Full Daily
-------- -------- --------
Estimate Time (hrs:min) 0:23
Run Time (hrs:min) 3:03
Dump Time (hrs:min) 1:09 0:54 0:15
Output Size (meg) 2688.6 2499.4 189.2
Original Size (meg) 7214.6 6792.5 422.2
Avg Compressed Size (%) 33.2 33.3 32.1
(level:#disks ...)
Filesystems Dumped 29 6 23 (1:23)
Avg Dump Rate (k/s) 660.9 788.9 210.2
Tape Time (hrs:min) 1:58 1:49 0:08
Tape Size (meg) 2690.1 2499.7 190.3
Tape Used (%) 70.8 65.8 5.0
(level:#disks ...)
Filesystems Taped 29 6 23 (1:23)
Avg Tp Write Rate (k/s) 390.5 390.3 391.8
--------------------------------
Note that the reported Original Size is well above the roughly 3.8
gigs set in the DDS2 tapetype, and yet amdump knew it would fit
once compressed. I'm beginning to feel a bit like pooh, the bear
of very little brain here...
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.19% setiathome rank, not too shabby for a WV hillbilly
|
