On Thursday 10 July 2008 18:50:54 Josh Fisher wrote:
> 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.
Thanks for trying, but unfortunately, the above is not how the current
Migration and Copy jobs work with the Next Pool. Though this could work, it
is (IMO) too complicated and would generate a lot of support requests. A
consistent syntax is important to maintain.
>
> >> 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-devel mailing list
> Bacula-devel AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-devel
-------------------------------------------------------------------------
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
|
