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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
