Re: [Duplicity-talk] duplicity 0.7 slowness

[Kenneth Loafman]

I am unable to reproduce this at all.  What is the filesystem where the archive-dir lives, what type?

What OS?  Why not upgrade to 0.7.09 from the PPA or the tarball?

On Sun, Jul 31, 2016 at 7:16 AM, Philip Jocks via Duplicity-talk <address@hidden> wrote:

Hej,

> does it keep being fast after recreating the archive dir?

you mean on an empty archive dir? Yes, still fast, the working directory (hash of the target URL) inside the archive dir stays empty.

>
> ..ede/duply.net
>
> PS: Aaron reworked file selection lately. another user came up w/ a patch that accelerates duplicity by magnitudes, maybe you want you try it? https://code.launchpad.net/~mwilck/duplicity/0.7-series/+merge/301332

yes, I just tried it (replaced globmatch.py and selection.py), but nothing is gained, collection-status still takes >50sec with —name vs. <1sec without —name.

Does —name have any other purpose other than having human readable working directories in the archive-dir vs the hash of the target URL? For me, leaving out —name would be fine, duplicity even mentions the directory while running, maybe adding a switch to duply might even suffice for the time being.

Am I the only one seeing this or is anyone else able to reproduce it? Currently testing it with a backup set of 300+ volumes of 200MB each, it might not be so sever with smaller sets, though it seems it isn’t even a matter of file size since it seems to only list difftar files etc, no real gpg magic etc.

Cheers,

Philip

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk