Hi Arno, On Mittwoch 13 Februar 2008 22:47:45 wrote: > 13.02.2008 20:59, Falk Sauer wrote:
> > 13-Feb 19:25 save-sd JobId 2516: End of Volume "HB0074" at 311:10733 on > > device "Drive-2" (/dev/nst1). Write of 64512 bytes got -1. > > 13-Feb 19:26 save-sd JobId 2516: Re-read of last block succeeded. > > 13-Feb 19:26 save-sd JobId 2516: End of medium on Volume "HB0074" > > Bytes=311,672,503,296 Blocks=4,831,232 at 13-Feb-2008 19:26. > > 13-Feb 19:26 save-dir JobId 2516: Using Volume "HB0081" from 'Scratch' > > pool. 13-Feb 19:26 save-sd JobId 2516: 3307 Issuing autochanger "unload > > slot 18, drive 1" command. > > 13-Feb 19:27 save-sd JobId 2516: 3304 Issuing autochanger "load slot 20, > > drive 1" command. > > 13-Feb 19:32 save-sd JobId 2516: Fatal error: 3992 Bad autochanger "load > > slot 20, drive 1": ERR=Child died from signal 15: Termination. > > Results=Loading media from Storage Element 20 into drive 1...Source > > Element Address 4115 is Empty > > mt: /dev/nst1: Kein Medium gefunden > > The Problem is imho the logic of changing tapes has not unload HB0081 > > from Drive-1 before attempt to load it from Slot 20 or, if using HB0081 > > is the 2nd best idea*, he should attempt to use a other pruned tape from > > Scratch pool. > > I think the right thing to do would be to unload drive one first... > anyway, this seems to be a bug worth reporting on bugs.bacula.org. ok, i file a bug, if your opinion is right, here we have 2 possible errors 1. the tape change logic 2. the sd termination in this case, on a lib with 2 drives where one goes in error state, the other one can work thru the end of his job or thru the end of the possibly queued jobs. This is imho not an error state - only a warning state, with blocking the hanging drive for all following jobs. I we imaging a lib with 3 or more drives and big long running jobs, dying of the sd is imho not the right solution if only one of them hangs. The imho best solution can be a drive switch. > What would be interesting is the internal state of the SD at the time > this happens, i.e. is it aware that the tape needed is in drive 1? I > *guess* the tape is known to be loaded but not reserved. the normal state after 'label barcodes', whatever this state is. ;-) > I'm not aware of this bug, but you surely will look if something > similar is already reported, right? ;-) i will take a look into the bug database, i'm unshure but i didn't read such a bug on the buglist in the past (from 2.2 on). Regards Falk ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
