Re: [Bacula-devel] new jobs cannot spool until existing jobs finish despooling?

[Marco v. W. <mv...@pl...>]

Stephen Thompson <stephen <at> seismo.berkeley.edu> writes:
> 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.
> 
Taking a quick peek at the code:

src/stored/append.c:do_append_data

calls acquire_device_for_append which as far as I know want
a tape drive it can write to, are your jobs in state running
or only scheduled e.g. the ones that are waiting to spool.
Because after the acquire_device_for_append succeeds the
state of the job is set to RUNNING.

The whole spooling is setup after that and then it 
writes the session header and after that the
fd is told it can send its data.

I guess you are stuck there. It may not be obvious but maybe
we could only reserve the drive and start the spooling
but then we need to write the session header the moment we
start despooling after we have actually acquired the storage
which we reserved earlier. Its not obvious if this might work
and as the SD is kind of interesting I'm not sure this
is going to work.

> 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.
> 

If your jobs are stuck in probably a non-running state we can almost
be sure its hanging on the acquire call. As to budget you have to ask
Bacula Systems maybe its not as bad as you make it sound.

Marco