From: David Boyes <dboyes@si...> - 2007-03-24 20:38:32
> 1. Previous when Bacula needed a new Volume, it would prune *all*
> in the current pool. Now it prunes only one at a time, until it
> that has been Purged. This means that less pruning will be done,
> database records will tend to remain longer (possibly much
> Although individual volumes can be prunned by command, there is no
> command to prune a whole pool.
> Question: does anyone feel there is a need for a new command that will
> pemit manually pruning a whole pool? An appropriate
> *may* be dbcheck.
I'd suggest that it already exists via migration. Running a migration
job with the source and destination pools set to the same value, and
specifying a selection criteria of volume occupancy threshold < some
value would accomplish the same effect if you set the occupancy
threshold to < 1%. You'd also get the side effect of consolidating the
volumes in the pool to a smaller number at the same time.
> 2. Currently, the "status dir" command will do pruning while
> find the Volume name to list if no current Volume is available.
> many users have complained about this because it can be *very*
> consuming. The new code will be slightly faster because it will
> a volume is Purged rather than pruning the whole Pool. However I
> considering disabling pruning by default from the "status dir"
> but allow the user to optionally specify "status dir prune" to turn
> back on. Note, there is a "list nextvolume" command which will
> to prune by default.
> Question: does anyone object to turning off pruning in the "status
> command or have a better idea?
Turn it off.=20
Get latest updates about Open Source Projects, Conferences and News.