Thanks to all who have responded so far.

1st, I am aware that what is in debian and ubuntu is not the latest and
greatest.  Indeed, it appears to me that what is in ubuntu is just
debian.  I did not see any bug reports in the ubuntu archives for
amanda.  So, I suspect that there is no real active development over on
the ubuntu tree for amanda, but I do not really know.  I am grateful
that ubuntu does offer amanda in their archives.

Under the Debian tree, there are 3 bug reports.  2 of these are wishlist
items, and the 3rd is a security-related bug that is unrelated to this
issue.

It could be that the upgrade to jaunty has nothing to do with this at
all, and it is just my own suspicion.  I have never had timeout errors
before.

My workaround worked last night and I was able to get all the backups
working by running a large value for dtimeout.

I will work on your recommendations below, and report back if I find
anything.  I think I only have a single gzip process in which case I am
just seeing a long time for gzip of the index.  This would make sense.
As to why my index takes longer, don't know.  

On Wed, 2009-05-13 at 10:01 +0200, Paul Bijnens wrote:
> On 2009-05-13 00:24, James D. Freels wrote:
> > I got into debugging mode and discovered why this was happening.
> > Apparently this upgrade, or a recent change in AMANDA, now forces (or by
> > error) the data to be compressed with gzip before going from the client
> > to the server.  Even if I specify "compress none" (which I always have)
> > or "compress client none" and "compress server none", the gzip is still
> > going on.  
> > 
> > I have never seen this before, and the gzip process is taking forever
> > for my large filesystems.  I can't seem to get it to stop.
> 
> Note that the index is always gzipped, even when you using "compress none".
> Did you came to this conclusion because there is "a" gzip process running?
> Or do you have indeed two gzip processes, and one (or both??) are slowing
> down everything?
> Or do you have a pathological filesystem where the name of the files
> is more data than the contents of the files?
> 
> To hunt down what a client is doing I often use "lsof" on the gnutar
> process to find out what file it is currently reading.  Maybe you
> got stuck on some unresponsive network filesystem (smb is frequently
> doing that -- I avoid mounting smb filesystem since I got burned badly).
> To get even more details you can "strace" the process as well.
> 
-- 
James D. Freels, Ph.D.
Oak Ridge National Laboratory
freelsjd AT ornl DOT gov