On Sat, Nov 14, 2015 at 01:15:01PM +0100, Evgeni Golov wrote:
> The backup --pretend runs also differ:
> 1.18.1-1:
> % obnam backup --pretend
>
> Backed up 379360 files (of 432716 found), containing 5.0 GiB.
> Uploaded 58.0 GiB file data in 2m52s at 345.1 MiB/s average speed.
> Total download amount 24.0 MiB.
> Total upload amount 0.0 B. Overhead was 0.0 B (0.0 %).
> obnam backup --pretend 148.86s user 9.23s system 91% cpu 2:52.69 total
>
> 1.17-1:
> % obnam backup --pretend
>
> Backed up 1243 files (of 54599 found), containing 5.0 GiB.
> Uploaded 585.0 MiB file data in 28s at 21.1 MiB/s average speed.
> Total download amount 24.0 MiB.
> Total upload amount 0.0 B. Overhead was 0.0 B (0.0 %).
> obnam backup --pretend 25.60s user 0.93s system 94% cpu 27.996 total
>
> And yes, 1.18.1 seems to actually upload 58GiB of data (at least my
> backup LV run out of space but had about 20GiB free before) when I
> tried a real backup.
>
> What I find interesting that "containing 5GiB" is present in both runs.
git bisect...
28fbb8fab29b4488aa03ec95c18a80b97010f278 is the first bad commit
commit 28fbb8fab29b4488aa03ec95c18a80b97010f278
Author: Lars Wirzenius <l...@liw.fi>
Date: Sat Oct 24 14:32:01 2015 +0300
Reimplement scan_tree without recursion
Previously, scan_tree would, when encountering a very deep directory
tree, crash due to Python's maximal stack depth limit. To avoid that,
avoid recursion and use an explicit list of unprocessed items.
:100644 100644 e488632574514d277455fe16eb71ec73b54063f0
8bdf9a956cfe3819a42d32e56989de10e01801ee M NEWS
:040000 040000 d17f8434c67ad39e2095bcd1336126a1d3d62e3b
7a67f77d92a05bdcfa0ce543f9c2b0af81604b01 M obnamlib
HTH
Evgeni
