On 8/31/2010 5:44 AM, Marco Lertora wrote:
>    Hi!
>
> I've the same problem! anyone found a solution?
>
> I have 3 concurrent jobs, which backup from different fd to the same
> device on sd.
> All jobs use the same pool and the pool use "Maximum Volume Bytes" as
> volume splitting policy, as suggested in docs.
> All job has the same priority.
>
> Everything starts good, but after some volumes changes (becouse they
> reach the max volume size) the storage lost the pool information of the
> mounted volume
> So, the jobs started after that, wait on sd for a mounted volume with
> the same pool as the one wanted by the job.
>
> Regards
> Marco Lertora
>
>
I have seen something very much like this issue, except with tape 
drives.  I was trying to document it more fully before sending it in.

It seems that for me, after a tape change during a backup, the SD 
doesn't discover the pool of the mounted tape until after all currently 
running jobs complete, so no new jobs can start--once all running jobs 
finish, the currently mounted volume's pool is discovered by the SD, 
then any jobs stuck because the pool wasn't known can start.  I didn't 
know a similar or the same issue affected file volumes--it is relatively 
rare that I hit the tape volume version of this problem, since not very 
many of my backups span tapes.

If this is easily reproducible with tape volumes, someone should file a 
bug report.

-se



------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users