Amanda-Users

Re: wasted action of taper

2003-05-16 13:27:57
Subject: Re: wasted action of taper
From: Gene Heskett <gene.heskett AT verizon DOT net>
To: Jon LaBadie <jon AT jgcomp DOT com>, amanda-users AT amanda DOT org
Date: Fri, 16 May 2003 13:25:18 -0400
On Friday 16 May 2003 11:02 am, Jon LaBadie wrote:
>On Fri, May 16, 2003 at 07:10:20AM -0400, Mitch Collinsworth wrote:
>> Taper chunking opens the door to backing up DLEs that are larger
>> than a single tape, something which no amount of algo-shuffling
>> is going to accomplish.  It also opens the door to allowing
>> taping and dumping of a single DLE to proceed in parallel, which
>> can be a huge time-savings for large DLEs.  These are both
>> features that a lot of people would like to have.  They've also
>> been common deal-breakers for folks looking at amanda in the
>> past.
>
>Mitch,
>clarify for my your notion of "taper chunking" and the mentioned
> parallelism.
>
>In your view, if chunking is implemented, it would allow a DLE to
> be taped in chunks before the dump had completed.  This would
> certainly reduce the maximum size required for some holding
> disks.  Yet could only be used if a holding disk were provided.
>
>Do you anticipate the chunks of any specific DLE to be taped
> sequentially? I.e. once started, taping only continues for that
> DLE until completed? Or do you anticipate interleaving the chunks
> of multiple DLE's?  I can forsee difficulty with both approaches
> compared to only taping when a dump of a DLE is completed, with
> chunks for tape spanning of course.
>
>BTW in practice, doesn't the existing parallelism of amanda pretty
> much eliminate the time-saving benefits that these proposals
> might realize? Taping of completed DLE's goes on while my large
> DLE's complete and other DLE's dump while my large DLE's tape.

One other item that should be considered if taping as soon as the 
chunk is available is done, and that is the relative speed of the 
compressor (usually gzip) compared to the i/o rate of the drive.  
I'd certainly want to avoid the situation where the drive was 
starved for data and quits streaming.  With my relatively slow DDS2 
drive, I doubt it would be a problem, but can "gzip best" spit out 
chunks at 20+mb/sec for some of the latest big drives?  "No way 
josea" would be my first response.  The hardware hasn't gotten that 
fast *yet*.

Thats one of the reasons I do a dumporder string of all capital S's 
here, once its got the biggest one and starts to pour it down the 
pipe to the drive, it has plenty of time to get the next biggest 
one smunched and into the holding disk, so the drive streams 
non-stop till its done.

Just my $0.02 :)

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.


<Prev in Thread] Current Thread [Next in Thread>