Hi,

I just wanted to report a PEBCAK that I just went into, as reference for 
others.

Short setup description: I wanted to fully backup the 1.5TB on my Linux 
workstation to two 1TB USB hard disks, using amanda 2.6.2alpha-20090130 and 
'tpchanger "chg-disk:/backup/amanda"', with GNUTAR onto 40GB vtapes (24 slots 
on each USB disk), no holding disk, "tape_splitsize 4 gbyte" and 
"fallback_splitsize 1 gbyte". Of course, I needed a "split_diskbuffer" for 
splitting, and I put it to "/data/scratch".

After roughly 68 hours being afk, I had 1129GB on the USB disks (yes, I'll 
take a look into performance soon). I recognized that the (non-)performance of 
the backup degraded even more in the last 12 hours, and it had merely 64byte/s 
write speed then.

A quick peek with strace showed that the taper process was mainly doing
  getdents64(3, /* 85 entries */, 4096)   = 4080
and I discovered there were 230952 32KB files in /backup/amanda/drive0/data/. 
A sample look at two of them showed that they contained only 0-bytes after the 
header.

After some more digging with the great help of DJ Mitchell on IRC, he gave the 
crucial hint: I didn't exclude the "split_diskbuffer" location from backup!

Another quick check with "ls -l /proc/`pidof taper`/fd/" showed me it was 
really true, the taper was happily reading its own amanda-split-buffer-* files 
(marked as (deleted) but it nevertheless had the file handles), writing them 
again as amanda-split-buffer-* files...

*** So, be sure to have your "split_diskbuffer" in the exclude list. *** :)

Maybe there will be some fix some day (tar eg. also (now) recognizes its 
currently created archive and won't read it), but I see that this is probably 
not the most urgent part to work on.

Yours, Uwe