quak backup works on up to the content pool's limit of originals at once (closes #182)
check / check (push) Canceled after 0s
check / check (push) Canceled after 0s
lib.backup() ran its originals one at a time, so the content pool's five slots, or the contentConcurrency of the pools a library was opened with, went unused. The work for one original, its verify hashing included, is now storeOriginal, and that many workers take files from one iterator over the backup's files, so no more originals than the limit are open at once. BackupLibrary gains contentConcurrency, which the library sets from its content pool. The README's "Request pools" says so. Model: opus-5-5
This commit is contained in:
@@ -25,6 +25,14 @@ declares one.
|
||||
|
||||
# Completed Steps
|
||||
|
||||
- 2026-10-14: `lib.backup()`, and so `quak backup`, works on up to the content
|
||||
pool's limit of originals at once, 5 by default, instead of one at a time
|
||||
(issue 182). That many workers take files from one shared list, each doing all
|
||||
the work for one original, its `--verify` hashing included, so no more
|
||||
originals than that are open at once. `BackupLibrary` says the limit as
|
||||
`contentConcurrency`. A test holds each download at the fake Ente server to
|
||||
count those in flight.
|
||||
|
||||
- 2026-10-14: `quak backup` no longer asks the server for changes every 3
|
||||
seconds while it runs (issue 183). It opens its library with
|
||||
`refreshIntervalSeconds: Infinity`, which the library now takes as no
|
||||
|
||||
Reference in New Issue
Block a user