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
