Hello,

I have not seen your original post so I respond only to comments you mention below without understanding the full issue.  Yes, there can be typically a few seconds delay between when a volume is chosen for use and when it expires.  The use duration is only checked when the volume is first selected and not at any other time during running the job.  This can mean that a volume will be used for more time than specified in the use duration.  It would not be easy to fix this, and any simple fix might cause performance problems so you must be aware of this restriction.

By the way, there were quite a few race conditions concerning use durations and other time periods that affect whether or not a volume can continue to be used.  Many of these race conditions were fixed in 7.0.5.  If you are having problems with volumes, I strongly recommend upgrading.

Best regards,
Kern

On 14-10-16 07:28 PM, Giuseppe Vitillaro wrote:

Apologies for appending to my own post, but I found
another occurence of the same pattern, I didn't notice,
in another job of some months ago, again attached to
this message. The same volumes are involved, and these,
for what I can see from my logs, are the only occurences
of the pattern.

It looks like that a volume exceeding the "use duration"
once the job has choosed the backup volume, create this
problem.

May I guess the routine "find_next_volume_for_append()"
in the source next_vol.c of the director could have
a bug, at least in the version 5.2.13 (19Jan13) I'm using?

In all the other cases I've verified, almost one year
of correctly running jobs, the "use duration"
have not been checked just after the beginning of the
job, once the director has already decided the volume
to use, but at a different time.

I may be on the wrong track, but if I'm right bacula
may overwrite a non empty, not purged volume.

Something, I guess, all the bacula users would hate,
isn't?

G. Vitillaro.

I can't understand why the bacula director, 5.2.13 under a stable updated gentoo, recycled one volume "000506L4", the correct one in the slot 9 of my changer, but instead the storage daemon recycled the current volume mounted in drive1, from slot4, volume "000529L4" and without actually doing any pruning on the volume, pruning that was correctly performed for the "000506L4" volume.

Note that the volume "000506L4" exceeded "Max configure use duration" just before the records for volume "000506L4" had been pruned.

After this I've just a sequence, complete log attached to this message, of

Recycled volume "000506L4" Recycled volume "000529L4" on device "lto1" (/dev/nlto1), all previous data lost.

This configuration of bacula had been running for quite a while without a glitch, almost 10 months now and I had not any hardware error on my library at the time of this job, at least for what I can see.

I can't understand what is going on.

Any clue?

Regards, G. Vitillaro.

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho

_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho

_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users