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 freel...@ornl.gov
