On 9/25/2019 4:50 AM, Andrea Venturoli wrote:
On 2019-09-25 10:19, Radosław Korzeniewski wrote:
Hello,
sob., 21 wrz 2019 o 00:52 David Brodbeck <brodb...@math.ucsb.edu
<mailto:brodb...@math.ucsb.edu>> napisał(a):
I think this is a somewhat unfortunate design decision, to be
honest. (...)
So what should be the best design in this case which should solve the
problem?
I'm not so into the code to tell for sure.
Maybe rescheduling should release the SD once the job first fails and
reserve again when it starts the next time?
I've always thought that these device and/or volume contention issues
could be resolved by selecting both device and volume in an atomic
manner. Currently, the write device is selected once per job, then
separately, volumes are selected as needed. My thought is to select both
device and volume as a pair each time that a volume is needed. (The
device-volume pair selection would need to be atomic to prevent a race
condition.) This place the focus on the volume, rather than the device
it happens to be on. This would seem to be less efficient, since every
volume selection would also require a device selection, but keep in mind
that device and volume selection do not happen that often, even with
large installations, and are a small part of the overall job time.
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
