RE: [Bacula-devel] find_next_volume_for_append algorithm issue

[David B. <db...@si...>]

> > the user the choice of canceling the job or mounting some=20
> acceptable Volume.=20
> > One must remember that the user is not obligated to mount=20
> the Volume=20
> > that Bacula requests.  Bacula will accept any Volume that=20
> the job has=20
> > permission to write to -- e.g. correct pool, media type, ...
>=20
> I think the logic needs to be more of any volume with=20
> inchanger=3D0 flag should not be eligible if there are any=20
> volumes in the changer that could be used.
> One example would be scratch tapes in the changer and all of=20
> a particular pool that is needed out of the changer. Instead=20
> of blocking for a tape from that pool, move a scratch tape=20
> into it and use that.

I could live with this behavior, or at least making it the preferred
behavior if I could turn it off for specific pools. If the default
changed to allowing use of scratch before failing, then I'd like to have
a "Permit Scratch Volume Selection =3D No" option work for a specific
pool.=20

> That would also apply to the case where a scratch tape will=20
> be used, it should definitely take one in the changer as=20
> opposed to asking for one outside of it.

I concur. If I've explicitly told the dir/SD that a volume is not
available, any mount attempt for that should be a last resort at best.=20