On Wednesday 03 September 2008 17:15:00 Jorge Cabello wrote:
> Hello,
>
> I haven't look the code and I'm not really skilled in bacula but ...
>
> Isn't this the same situation as a backup in the following conditions:
> * 1 Pool for full backups
> * 1 Pool for incremental
> * No differential backups
>
> In this configuration you must read and write from the full backups pool
> when you are doing a full backup. Even further, if the last volume of
> this pool isnt full you will try read and write to it having the same
> situation.
I imagine that you are right there could be deadlocks here too.
Deadlocks, occur in the sense I am discussing here, during Migration, Copy,
and Virtual Backup. For Migration and Copy they attempt guarantee that no
deadlock will occur by forcing reading from *one* pool and writing to another
pool.
In the case of a Virtual backup, reading may come from multiple pools, which
are hopefully all different from the write pool. The problem occurs once a
virtual backup has been written to the write pool.
What I am looking for is a reasonable way to ensure that we can do multiple
Virtual Backups -- or a Virtual backup while reading a volume that was
written as a Virtual backup, and not have any obvious deadlocks, and what
makes it harder is to do so without adding deadlock code. In an ideal case,
we would have deadlock resolution code that would figure out a solution, but
that is not yet possible.
>
> El mié, 03-09-2008 a las 11:37 +0200, Kern Sibbald escribió:
> > Everything seems to work fine with the Virtual Backup. However, thinking
> > about longer term operations, it has occurred to me that when you want to
> > make a second Virtual Backup things will become very complicated. First,
> > the Virtual backup will want to read the previous Virtual backup volume,
> > and then if that Volume is not full, it will want to write to the same
> > Volume. Even if the volume is full, you will be in a situation where the
> > Job will want to read and write to volumes in the same pool. In all
> > those cases, there is no guarantee that there will not be a deadlock
> > situation (actually Bacula currently cancels any job attempting to read
> > and write from the same Storage device).
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
