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.

--
Paul Bijnens, Xplanation Technology Services        Tel  +32 16 397.525
Interleuvenlaan 86, B-3001 Leuven, BELGIUM          Fax  +32 16 397.552
***********************************************************************
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, ~., *
* stop, end, ^]c, +++ ATH, disconnect,  halt,  abort,  hangup,  KJOB, *
* ^X^X,  :D::D,  kill -9 1,  kill -1 $$,  shutdown,  init 0,  Alt-F4, *
* Alt-f-e, Ctrl-Alt-Del, Alt-SysRq-reisub, Stop-A, AltGr-NumLock, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************