I had to try a dozen backed up versions of a file one after another to find a
lost edit and I was also greatly annoyed by the delay (~6 minutes with a fast
USB3 disk). So I noticed this report and also noted that duplicity indeed does
many tenths of thousands to half a million sys-calls to stat
Ooops I just noticed this bug is ancient -- hope my report helps anyway.
BTW this was on a healthy and patched Ubuntu 16.04.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to duplicity in Ubuntu.
https://bugs.launchpad.net/bugs/1090725
Tit
Is this still a problem? Note that the bug has expired as of lack of
activity. Please, change it to 'New' if it still happening.
The actual backup operation in deja-dup is done by the duplicity program
instead, I'm moving it into that package. Also, it's probably a problem
in the upstream program,
strace -c output was attached.
We can not see 'read' here because /etc/passwd is just mapped on memory.
The actual reading is beyond of strace scope.
** Attachment added: "strace -c output for duplicity"
https://bugs.launchpad.net/ubuntu/+source/deja-dup/+bug/1090725/+attachment/3919109/+file
[Expired for deja-dup (Ubuntu) because there has been no activity for 60
days.]
** Changed in: deja-dup (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
https://bugs.launch
Can you check how much effective time the reads add? I think that strace has
some option to do so (maybe -c)
Even if unnecessary reads, those files tend to be quite small and the number of
that you show here should not add a lot of overhead in the total run.
Thanks in advance!
** Changed in: dej
6 matches
Mail list logo
