Is it possible to disable autopack?

[Robert Collins]

On Fri, 2008-11-28 at 17:42 +0100, Christian Tschabuschnig wrote:
> I'm doing file-based remote backups of a bazaar repository. The
> revisions often have several megabytes. I want to disable autopacking
> because the consolidation every 10 commits costs a lot of bandwith. Is
> there a option to disable autopacking for a single repository?

Objects get moved logarthimically less frequently as time goes on. The
first commit writes it once, the 10 again, the 100th again. essentially,
bzr is built on a database with a 'row storage' focus, and we
incrementally aggregate rows together to balance latency (which has a
minimum factor largely determined by the number of files on disk) and IO
(compacting everything every time gives optimal latency but pathological
IO on write operations).

So if you do 9 commits a day, at 10 MB each, or 90MB new data.
day 1 will give you one 9 new 10MB packs. = 90MB
day 2 will give you 1 new 100MB pack, 8 new 10MB packs = 180MB
day 3 will give you 1 new 100MB pack, 7 new 10MB packs = 170MB
day 4 will give you 1 new 100MB pack, 6 new 10MB packs = 160MB
day 5 will give you 1 new 100MB pack, 5 new 10MB packs = 150MB
day 6 will give you 1 new 100MB pack, 4 new 10MB packs = 140MB
day 7 will give you 1 new 100MB pack, 3 new 10MB packs = 130MB
day 8 will give you 1 new 100MB pack, 2 new 10MB packs = 120MB
day 9 will give you 1 new 100MB pack, 1 new 10MB packs = 110MB
day 10 will give you 1 new 100MB pack, 0 new 10MB packs = 100MB
day 11 will give you 0 new 100MB packs, 9 new 10MB packs = 90MB
day 12 will give you 1 new 1GB pack, 8 new 10MB packs = 1080MB
day 13 will give you 0 new 1GB packs, 1 new 100MB pack, 7 new 10MB packs = 170MB
etc

(back of hand summary: 
 1 new 100MB pack 9 days out of 10
 1 new 1GB pack 1 day out of 12
 1 new 10GB pack 1 day out of 108)

So no, it can't be disabled except by altering the code, because if it
is disabled repository performance will slowly but surely degrade. Each
revision data probe will involve N index queries rather than 1 index
query for the sum of the digits of N.

You can exclude the contents of obsolete_packs from your backup (but
backup the existence of the directory - its needed). Note that if you do
exclude obsolete_packs you will need to be more careful about not
writing to the bzr repository during a backup (because you may end up
with pack files that your root index points at that were obsoleted
during the backup process).

I've filed a bug that we don't allow a mechanism to tell bzr a backup is
in progress. You could abuse that to stop bzr obsoleteing thing
altogether - but see above, it is definitely not a good idea. You could
use it to reduce the perceived frequency of pack operations.

-Rob



-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081129/ec5fd2ae/attachment.pgp