On 3/21/12 8:47 AM, Marco van Wieringen wrote: > Stephen Thompson<stephen<at> seismo.berkeley.edu> writes: > >> >> >> On 3/21/12 8:02 AM, Stephen Thompson wrote: >>> >>> >>> Thanks for the response. >>> I am referring to this page in the documentation: >>> http://www.bacula.org/en/dev-manual/main/main/Data_Spooling.html >>> >>> I believe the above page is inline with what you say below. >>> >>> I am running 5.2.6 on Centos 5.8 with a tape library with 2 drives. >>> >>> When I have launched jobs together, meaning, when I launch a set of jobs >>> in quick successtion so that they all vie for tape device resources, and >>> as those are assigned, they begin spooling, I have observed the >>> behaviour described in the web page above and your email below. >>> >>> The case where I have not is this: >>> >>> Day 1, launch set of jobs which occupy all drives, and use Data >>> Spooling. These run as expected and smaller/faster jobs complete >>> sooner. A few jobs (say two large slow ones to emphasize the situation) >>> remain spooling for longer, but eventually reach their despooling phase, >>> at which point they both occupy one of my two tape drives. This >>> situations proceeds into Day 2. >>> >>> Day 2, launch a different set of jobs, and use Data Spooling. The jobs >>> from the previous day are still despooling, and occupying all available >>> drives. And there is plenty of spool space available. All jobs in this >>> example have the same priority, level, use the same pool, to which the >>> tapes in the occupied drives belong, and there are no concurrencies >>> being exceeded. >>> >>> What I see for these new jobs, is that they do NOT begin to spool. >>> There status in bconsole is: >>> >>> (for Director) >>> 12345 Full JOBNAME.0000-00-00_00.00.00_00 is running >>> >>> (for Storage Daemon) >>> spooling=0 despooling=0 despool_wait=0w >>> [I don't seem to have captured what they say in the device field.] >>> >>> They remain in this state until the jobs from the previous day finish >>> despooling and free up their drives, at which point the new jobs begin >>> spooling. >>> >>> After doing some reading, I wondered if it's not possible that they are >>> stuck in the state before despooling, which I believe is checking to seew >> >> sorry, correction: "in the state before spooling" > > I think you just run into Feature request 11: > > Item 11: Start spooling even when waiting on tape > Origin: Tobias Barth<tobias.ba...@web-arts.com> > Date: 25 April 2008 > Status: > > What: If a job can be spooled to disk before writing it to tape, it should > be spooled immediately. Currently, bacula waits until the correct > tape is inserted into the drive. > > Why: It could save hours. When bacula waits on the operator who must > insert > the correct tape (e.g. a new tape or a tape from another media > pool), bacula could already prepare the spooled data in the > spooling > directory and immediately start despooling when the tape was > inserted by the operator. > > 2nd step: Use 2 or more spooling directories. When one directory > is > currently despooling, the next (on different disk drives) could > already be spooling the next data. > > Notes: I am using bacula 2.2.8, which has none of those features > implemented. >
This seems similar, but in my case, I'm not waiting for a tape to be loaded, the proper tape is already in the drive, but being written to be another job. I see how it's possible the code is treating both cases the same, that the drive is unavailable (for whatever reason), therefore the starting job must wait. But there's a logical distinction, where if my starting job had started when the job that's despooling (and blocking the drive) was spooling, my job would have started and be happily spooling along while the other job despools. There's no contention for an appropriate volume in this case and it seems like (logically at least) my job should start. Stephen > And no nothing done is that respect as far that I know of > and your best bet is the Enterprise version to get the priority > raised for this feature request. > We're an academic/research lab, and don't have the budget for that, but thanks for the suggestion. I guess mostly, I am trying to confirm if this is expected behavior, as a first step. Stephen > Marco > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Bacula-devel mailing list > Bacula-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-devel -- Stephen Thompson Berkeley Seismological Laboratory step...@seismo.berkeley.edu 215 McCone Hall # 4760 404.538.7077 (phone) University of California, Berkeley 510.643.5811 (fax) Berkeley, CA 94720-4760 ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
