Problem with amdump and PORT-WRITE mode

I've just run several failed tests on a tape-spanning amdump backup where Idid not have enough holding disk space to stage the write to tape, so amandapicked PORT-WRITE mode, and the backup of that filesystem failed.

I've run this test 3 times, and all three times it failed with a "Syncpipefailure during tape advance" error. Unfortunately, a google search for thaterror message turned up no useful results. Here's the pertinent sectionsfrom one of the report emails:


--- cut here ---
FAILURE AND STRANGE DUMP SUMMARY:
  localhost  bigtest_20061203  lev 0  FAILED [data write: Broken pipe]
  localhost  bigtest_20061203  lev 0  FAILED [dump to tape failed]
  taper: FATAL writer: Syncpipe failure during tape advance

FAILED AND STRANGE DUMP DETAILS:

/--  localhost bigtest_20061203 lev 0 FAILED [data write: Broken pipe]
sendbackup: start [localhost:bigtest_20061203 level 0]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/bin/tar -f - ...
sendbackup: info end
\--------

NOTES:
...
  taper: tape DailySet1-030 kb 158843296 fm 33 writing file: No space left on 
device
  taper: continuing localhost:dbtest_20061203.0 on new tape from 125829120kb 
mark: [writing file: No space left on device]
  taper: tape DailySet1-043 kb 176419104 fm 34 writing file: No space left on 
device
  taper: continuing localhost:dbtest_20061203.0 on new tape from 298844160kb 
mark: [writing file: No space left on device]
  taper: tape DailySet1-046 kb 56125984 fm 12 writing file: short write
  driver: taper pid 12151 exited with signal 11
--- cut here ---

From the NOTES section, it looks like there was a write error on tape

DailySet1-046, but it appears that amanda didn't handle it correctly andcontinue on, but instead died and failed to dump the rest of the data withthe "Syncpipe failure during tape advance".

Is this something that should be handled, or is failure to continue expectedif there is a tape write error, even if the dump is setup to span tapes andthere are more tapes available?

It's also a little strange that after the dump died, it appears that thenext tape (DailySet1-047) was loaded by the changer successfully, and iteven looks like the first file on the tape (the amanda marker file) wasupdated, as "mt status" showed the tape was positioned at file #2 (file 1from mt's zero-based counting) and "mt tell" showed it was at block 2 on thetape.


Thanks.

Evan