-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kern Sibbald wrote:
> Hello,
>
> As you may remember, one of the things I am working on for version 2.1.x is
> performance. My most recent work on performance has been to review and
> re-write the pruning and purging code. Over the years, this code has been
> added to and patched, and there are a number of issues that I want to
> address:
>
> 1. Review the pruning algorithms to improve the SQL.
> 2. Pruning during "status dir"
> 3. User complaints that it requires two passes to recycle Volumes
>
> The basic algorithm for recycling volumes is documented in the manual, and it
> will remain unchanged. However, I have now re-written the prune/purge code
> to do the following things:
>
> 1. Reduce unnecessary SQL calls to a minimum
> 2. When pruning, submit SQL statements that prune up to 1000 jobs
> in a single SQL statement rather than 1000 separate SQL statements.
> 3. Prune only a single volume if the SD requests pruning rather than
> pruning *all* the volumes in the Pool.
> 4. After pruning a Volume, explicitly check if it can be marked as Purged.
> 5. Ensure that there are not multiple copies of the same code (pruning and
> and purging share a lot code, some of which was duplicated).
>
> The net result is not a huge gain in performance, except in a few exceptional
> cases, but the code base is much cleaner, and I believe I have corrected at
> least one case where pruning would be performed but Bacula did not detect and
> hence mark the Volume purged.
>
> There are two issues where I would appreciate a bit of user feedback:
>
> 1. Previous when Bacula needed a new Volume, it would prune *all* volumes
> in the current pool. Now it prunes only one at a time, until it finds
> one
> that has been Purged. This means that less pruning will be done, and
> database records will tend to remain longer (possibly much longer).
> 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 place
> *may* be dbcheck.
>
> 2. Currently, the "status dir" command will do pruning while attempting to
> find the Volume name to list if no current Volume is available. Many
> many users have complained about this because it can be *very* time
> consuming. The new code will be slightly faster because it will stop once
> a volume is Purged rather than pruning the whole Pool. However I am
> considering disabling pruning by default from the "status dir" command,
> but allow the user to optionally specify "status dir prune" to turn it
> back on. Note, there is a "list nextvolume" command which will continue
> to prune by default.
>
> Question: does anyone object to turning off pruning in the "status dir"
> command or have a better idea?
This is a very sticky issue. I object to status dir doing the pruning
(the way things currently are) based on the idea that one would
basically expect a status command to merely show status, not actually
perform any destructive work. However, there's really no accurate way to
show current status without doing the pruning. I would really expect the
pruning to take place on its own on the schedule -- I think this would
be most intuitive, but then there's the other angle: why shouldn't data
remain if the space it's occupying isn't needed? Though, I suppose this
would also speak against pruning on 'status dir', because one could end
up pruning tapes that could wait until the next backup when all the user
wanted to do was get status.
I don't know -- tough call. Configurable option?
- --
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer III
|$&| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGBsohmb+gadEcsb4RAi7jAJ4hsdle/mVH9qp7jBxSrJ4ttkuJ/ACgz6Mo
u0/7uq6QQfRpUItUrrm6sf4=
=/wZ9
-----END PGP SIGNATURE-----
begin:vcard
fn:Ryan Novosielski
n:Novosielski;Ryan
org:UMDNJ;IST/AST
adr;dom:MSB C630;;185 South Orange Avenue;Newark;NJ;07103
email;internet:[EMAIL PROTECTED]
title:Systems Programmer III
tel;work:(973) 972-0922
tel;fax:(973) 972-7412
tel;pager:(866) 20-UMDNJ
x-mozilla-html:FALSE
version:2.1
end:vcard
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
