On Sun, 25 Nov 2012 21:48:09 +0200
Toomas Aas <[email protected]> wrote:


> 
> Why doesn't Amanda write these 5 DLEs to tape while dumping the 6th  
> one? The tape drive isn't doing anything (amstatus shows 'Taper  
> status: idle'). I can't see any obvious parameters in amanda.conf
> that would control this. The current behaviour - first writing
> (almost) all the DLEs to holding disk and then from holdingdisk to
> tape - means that amdump run takes much longer compared to if the  
> 'wait-for-writing-to-tape' DLEs were taped simultaneously with
> dumping these DLEs that are later in the queue.

I'll take a guess, and others may jump in to tell me where I am wrong.

One problem with physical tapes is that stopping and then starting up
immediately is that this takes a *long* time. Stopping is not
instantaneous. Then, to restart where you left off involves backing up
and restarting, reading until you get to where you left off. It's also
rough on the tape and the drive. A lot of that in a short period of
time we call "shoe shining". Imagine the head as the shoe. So you want
to avoid stopping and starting.

The simplest way to do so is to wait until all the dumps are complete,
then tossing them all onto the tape drive. This assumes the holding disk
is big enough. Amanda is a bit smarter than that; it waits until it has
enough on the holding disk that it is a good bet it won't have to
stop and start. I don't know the exact algorithm Amanda uses, but I
expect it is selected to give you continuous writing once writing has
started, even if it means a longer run time.


> 
> If it matters, this is Amanda 3.2.0 using vtapes with chg-disk.

vtapes emulate physical tapes. And they are fast compared to physical
tape. So I suspect Amanda would wait longer to start writing than if it
were using a slow physical tape.



-- 

Charles Curley                  /"\    ASCII Ribbon Campaign
Looking for fine software       \ /    Respect for open standards
and/or writing?                  X     No HTML/RTF in email
http://www.charlescurley.com    / \    No M$ Word docs in email

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB

Reply via email to