hi...

I'm sorry for the delay in the reply, I was on vacations during easter,
and didn't had a chance to work on this.


> > > > but this does not work, gtar proccess are eating a lot of CPU cycles:
> > > > =====================================================================
> > > > > gtar --create --file - --directory /boot --one-file-system
> > > > > --listed-incremental 
> > > > > /root/gtar_test/gnutar-lists/172.31.3.9_boot_0.new
> > > > > --sparse --ignore-failed-read --totals --exclude-from
> > > > > /root/gtar_test/sendbackup._boot.20080320110639.exclude . 
> > The output goes to STDOUT. I haven't tested it myself but from the
> > vmware support I got the information that the moment you redirect the
> > output of gtar to a file the proccess finishes without failures....
> > 
> > see also the command options of the 1. and 3. example. they only differ
> > in the redirection of STDOUT.
> 
> Yes - it was not clear what you're doing with the data appearing on
> STDOUT of gtar.
> 
> What happens if you send it like:
> 
>     gtar ... --file - | cat >/dev/null
> 
> (The pipe/cat is necessary as othewise gtar will be too smart - it
> "sees" that you're sending STDOUT to /dev/null and doesn't produce any
> output.)
ok, I tested that, and gtar says that 26MB were written, which is the
size of the whole '/boot' folder content.

so any idea how to further troubleshoot this...

I have an open ticket at the vmware support, and they claim it's in the
way that amanda calls gtar and try to close the case as soon as
possible...

I'm not sure if they are right, so any help on troubleshooting this
problem quickly is appreciated.

Thanks,

Olli