On Fri, Jan 30, 2004 at 09:05:29PM -0500, Jon LaBadie wrote:

> > I set up amanda with chg-disk. By design, dumps are done to holding disk and
> > copied to the disk afterwards. This copy operation makes the machine pretty
> > much unusable for interactive usage (puts almost everything to swap).
> > 
> > Now I wonder whether there is a way to omit this copy operation. First
> > thought was to disable holding disk (or setting it to 0). But (AFAIK) this
> > would disable amanda's ability to dump several DLEs in parallel.
> 
> If you can design a way to simultaneously write several dump streams
> to a tape (remember you are emulating a tape) but have each of them
> appear on the tape as separate, contiguous files, perhaps some one
> could work on coding it.  But I doubt the design is possible. :(

Yes, I know. This is the reason that I asked whether it would be possible
to change the copy operation into a rename operation for the file: output
driver.

> Are you sure it is the copy operation that makes your system unusable?
> I would expect disk to disk copy to be a fairly short part of the
> total dump time and effort.

It is short compared to the total dump time. But it still takes several
minutes per DLE. This copy operation flushes all the buffer caches and
makes the system almost unusable for interactive operations.

> Is the holding disk the same physical drive as the virtual tapes?
> That would be a poor choice.

No. I have a separate disk for the virtual tapes.

> Are either/both the holding disk and the virtual tape disk IDE type
> drives rather than SCSI.  IDE drives do take substantial cpu cycles
> compared to SCSI drives.

The disks are IDE. But the problem is _not_ the cpu cycles. The problem
is that the copy operation fills all the buffer cache with the copied
data. This leads to lots of page faults making the system almost unusable.

> If you haven't tested the backup without a holding disk, perhaps you
> should.  It may surprise you with a sufficiently quick total dump
> time despite the lack of a holding disk.

This would loose the capability to dump several hosts in parallel.

> Are you doing server side compression rather than client side?

Nope.

> Compression processes take lots of cpu cycles from interactive sessions.

The problem is _not_ cpu cycles. The problem is the (unnecessary) copy
operation.

> You might consider setting a "nice" value on your backups.

amdump _is_ running with a high nice value. But this don't really help.
Again, the problem is that the copy operation fills all the buffer cache
and forces all the other processes into page faults. A high nice value
_can't_ help in such a situation.

-- 
-- Josef Wolf -- jw AT raven.inka DOT de --