Kern Sibbald wrote:
> On Thursday 10 July 2008 16:23:15 Josh Fisher wrote:
>   
>> ...
>> Why not always write vbackup jobs to a volume in a "special" pool first?
>>     
>
> Well, that is exactly what happens.  It is just called "Next Pool" rather 
> than 
> special pool.
>
> However, the Next Pool cannot be the same as the Pool from which the jobs are 
> going to be read.
>
>   
>> When writing to the volume(s) in the special pool is completed, either
>> the volume(s) could be moved from the special pool to the destination
>> pool specified by the job, or the entire vbackup job could be migrated
>> to the destination pool. 
>>     
>
> It sounds like you are more or less re-inventing the Scratch pool, but with a 
> slight twist.  It probably would work, but sounds a bit complicated to me.  I 
> suspect we would get a lot of support requests :-(
>   
Well, I meant to be re-inventing spooling (with a slight twist), rather 
than the Scratch pool. :)

What if having a Scratch pool was made a prerequisite for vbackup level 
jobs? Multiple concurrent vbackup jobs would be disallowed. At the end 
of a vbackup job, the Next pool volumes it has written are either moved 
into the destination pool for a successful job, or purged and moved back 
into the Scratch pool for a failed job, always leaving the Next pool 
empty. At vbackup job startup, any volumes in the Next pool are marked 
in error, since they must have been left by a previous vbackup job that 
aborted for whatever reason. Thus, volumes for the vbackup job are 
always pulled from the Scratch pool and moved into the Next pool. Data 
is only written to volumes in the Next pool, and those volumes can never 
interfere with any of the input pools, since they will not be moved into 
the destination pool until after the vbackup job is essentially 
completed. All the user has to know is that a Scratch pool with 
available volumes is required for running vbackup level jobs.


>> The former would be faster, but would likely 
>> waste space due to fragmentation if the destination pool was only used
>> for vbackup jobs. However, the destination pool could be the same pool
>> used for normal backups, and remaining volume space would be usable by
>> normal jobs. In either case, all normal pools (except the special pool
>> and the Scratch pool) could then be used for input, including the
>> destination pools of previous vbackup jobs. I would envision putting
>> vbackup jobs into the same pool I put normal full backup jobs.
>>     
>
> For the moment, I don't see any clean solution to this problem unless we 
> program logic to implement the concept of a "different" volume or if the user 
> does some manual intervention (moving of volumes between pools -- which rules 
> writing more vbackups to them).
>   

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users