On 12/9/2015 6:49 AM, Heitor Faria wrote:
Team,
Sometime 2 drives acquire same tape, though there are free
tapes available in pool.
Device get BLOCKED and backup stop until tape is not release.
Below option is enable in bacula-dir file.
Prefer Mounted Volumes = no
Can you suggest solution for this?
Hello Ankush: first of all please avoid making new questions in prior
existing topics unless they are specific related to it for the sanity
of the future readers of those discussions.
If you read the manual you can see that setting this directive to know
is not recommended at all:
"Despite the above, we recommend against setting this directive to
*no* since it tends to add a lot of swapping of Volumes between the
different drives and can easily lead to deadlock situations in the
Storage daemon. We will accept bug reports against it, but we cannot
guarantee that we will be able to fix the problem in a reasonable time.
A better alternative for using multiple drives is to use multiple
pools so that Bacula will be forced to mount Volumes from those Pools
on different drives."
Another alternative to multiplexing backup to different drives is to
limit Maximum Concurrent Jobs in each one of Devices resources in
bacula-sd.conf.
Yet, serializing the jobs to one drive sort of defeats the purpose.
Setting PreferMountedVolumes=yes in general means that jobs writing to
the same pool will all select the same volume, hence the need to limit
Maximum Concurrent Jobs in each Device resource. The net effect is that
multiple pools will be needed in order to make use of multiple drives
for concurrent jobs. That approach is effective and safe from the race
condition mentioned. However, it means that all of the jobs must be
manually dispersed into different pools and the admin must manually keep
the pools balanced over time as clients are added and removed.
Another approach is to give each client their own pool, guaranteeing
maximum concurrency while avoiding a race condition. However, that
approach will generally require more tapes and is only useful for a
small number of clients.
A more accurate way to describe the issue is to say "two JOBS were
assigned the same volume, but they were assigned different drives",
rather than "two DRIVES were assigned the same volume".
It was a design choice that a job is initially assigned a Device, then
is separately assigned a volume. It is understandable, since a job may
require more than one volume and so will need to go through volume
assignment multiple times. What I don't understand is why that initial
Device assignment must be permanent for the life of the job. I would
prefer that jobs were assigned a Device+volume pair as a single atomic
operation. When a job requires a second volume it would then relinquish
the pair, both Device and volume, and be queued for assignment of
another Device+volume pair. Yes, this is a complex topic and requires
queuing jobs and serializing the Device+volume selection code with a
mutex, but it is certainly possible. I believe that removing the
permanent Device assignment would alleviate or eliminate these volume
selection race condition issues.
Regards,
===========================================================================
Heitor Medrado de Faria - LPIC-III | ITIL-F | Bacula Systems
Certified Administrator II
Do you need Bacula training? http://bacula.us/video-classes/
+55 61 <tel:%2B55%2061%202021-8260>8268-4220 <tel:%2B55%2061%208268-4220>
Site: http://bacula.us FB: heitor.faria
<http://www.facebook.com/heitor.faria>
===========================================================================
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
