Here's the mt status after a run that used 2 tapes:

SCSI 2 tape drive:
File number=3, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x80 (DLT 15GB uncompressed).
Soft error count since last status=0
General status bits on (81010000):
 EOF ONLINE IM_REP_EN

On this run, the first tape does not appear to contain the *reported* 
backup images.  So in effect, none of my backups took place while amanda 
says otherwise.

Sure, I can give 2.4.4b1 a try.  I've tried every other release.  :)
Before I noticed the tapes acting funny.  I know that that last dumper 
line in amreport did occur and was never a problem.



robin


On Wed, 19 Feb 2003, Joshua Baker-LePain wrote:

> On Wed, 19 Feb 2003 at 2:17pm, rwong AT mrs.mni.mcgill DOT ca wrote
> 
> > I've attached a run using the unix tools.  There were messages in the log 
> > which I've also attached.
> > 
> > Another symptom I've noticed is that when amanda uses multiple tapes.  The 
> > first tape will not be accessible by the amanda tools but mt/dd can read 
> > the fileheaders and read the backups.  But the tapes following the first 
> > are never readable by amanda nor mt/dd.
> 
> This is from the amreport email you sent:
> 
>   taper: tape tape-08 kb 31302464 fm 63 writing file: No space left on device
>   taper: retrying host1:/disk1/bs/.donnotrm01.0 on new tape: [writing file: No
> space left on device]
>   driver: dumper0 pid 10771 is messed up, ignoring it.
> 
> That last line is, I believe, a bug that remained through 2.4.3 final.  It 
> *could* lead to the second tape not being readable, but I'm not so sure 
> about that.
> 
> Can you try 2.4.4b1?  If it makes you feel better, I'm using it in 
> production on my larger config (1.5TB worth of (used) RAID space backed up 
> to a Overland AIT3 changer) with good results (including working 
> amrecover).
> 
> Also, can you try writing multiple tarfiles to a tape, ejecting the tape, 
> then reading back some of them?  The errors in the system logs are 
> indicating some sort of issue with reading.
> 
>