Re: [PATCH v2 proxmox proxmox-backup 0/3] datastore: gc: defer and batch chunk atime updates

[Christian Ebner <c.ebner@proxmox.com>]

On 9/5/26 10:32 PM, plantulli@gmail.com wrote:
> Hi,
> 
> as promised in my last mail: the first full end-to-end GC cycle with the
> v2 (deferred, batched atime updates) design has now completed on datastore
> A. Headline number first:
> 
>    start: 2026-08-18 18:52:33
>    end:   2026-08-22 18:11:54  (TASK OK)
>    total: 3 days 23h19m
> 
>    phase 1 (mark, deferred batch, size 1,048,576):  59.3h
>    phase 2 (sweep):                                 36.0h
> 
>    removed garbage:  9.818 TiB
>    removed chunks:   5,242,712
>    on-disk after:    121.78 TiB / 64,562,152 chunks
>    dedup factor:     10.55
>    chunk cache hit ratio: 80.95%
> 
> For the same store, that makes the series so far:
> 
>    historical (six cycles, unpatched):  21.25 - 65.81 days
>    v1 (whole-store prefetch):           7.33 days
>    v2 (deferred batch):                 3.97 days
> 
> The binaries were the v2 series as posted, plus the per-run warmed-
> directory tracker I described in my previous mail (skips the redundant
> readdir when a later flush revisits an already-warmed directory).
> 
> Where the gain actually came from, with the honest caveats:
> 
> * Phase 2 is the big win: 36.0h vs 121.4h for v1. Normalized per swept
>    chunk that is ~193 -> ~538 chunks/s (~2.8x) on a comparable sweep size
>    (84.2M vs 69.8M chunks). One caveat: this cycle had ~3.5x fewer chunks
>    to actually unlink (5.2M vs 18.2M), and unlinks are the expensive part
>    of the sweep, so the per-chunk rate comparison flatters v2 somewhat.
>    Even discounting that, the sweep clearly benefits from metadata still
>    being warm from the flush readdirs, where in v1 the upfront prefetch
>    had been evicted long before phase 2 started.
> 
> * Phase 1 was comparable to v1, not faster: 59.3h vs v1's 53.5h plus a
>    1h upfront prefetch. Consistent with what I reported earlier about the
>    first flush on a cold store at the default batch size: warming up to 1M
>    chunks spread over nearly all 65,536 directories in one synchronous
>    flush is a lot of work in one place. This is more support for making
>    the batch size independently tunable for benchmarking, as you
>    suggested; I briefly started a run at batch size 131,072 but aborted it
>    for unrelated operational reasons, so I don't have a clean comparison
>    yet.
> 
> * This run did not start fully cold: the v1 cycle had finished about a
>    day earlier, so some metadata was still cached. The next scheduled run
>    on this store (Sep 16) will be a cold start; I'll report back if the
>    picture changes materially.
> 
> Also worth noting: on our smaller datastore B (~10M chunks), daily GC
> with v2 is now routine at ~40-50 minutes total, with phase 1 around 15
> minutes - down from over 17 hours for phase 1 alone before this work
> started.
> 
> Thanks,
> Enrico

Thank you for your additional information, there still is room for 
further optimization as I tried to emphasize in my review of version 2 
of the patch series, please take that into consideration as well.

Thanks!