Found while reviewing #182 (#89). Checked against next at be6c715.
When cache_max_bytes is not set, ComputeDefaultCacheMaxBytes in internal/config/cachesize.go makes the limit 75% of the space free on the cache's filesystem at startup. The cache's own files are not free space, so the limit drops as the cache grows. On an otherwise empty 100 GB disk: the first start allows 75 GB; once the cache holds 75 GB, the next start sees 25 GB free and allows about 19 GB, and eviction deletes about 56 GB of cached images; the start after that allows about 61 GB again. A deployment that restarts on every deploy keeps throwing most of its cache away. README.md now tells operators to set cache_max_bytes, but the default should not behave like this.
Plan:
The default counts what the cache already holds as space it may use: 75% of (free space + the bytes the cache already holds), with the 500 MiB floor as now. What the cache holds comes from the cache's own size accounting where the cache is opened (Cache.UsageBytes in internal/imgcache), not from walking the directories at startup; so the default is worked out there, after the database is open, and logged as now.
Test first: with a fake free-space probe and a cache already holding N bytes, the default is 75% of (free + N), so a full cache keeps its limit across a restart.
README.md, where it describes the default, says what it counts; the advice to set cache_max_bytes for a lasting deployment may stay.
Model: opus-5-5
Found while reviewing https://git.eeqj.de/sneak/pixa/pulls/182 (https://git.eeqj.de/sneak/pixa/issues/89). Checked against `next` at `be6c715`.
When `cache_max_bytes` is not set, `ComputeDefaultCacheMaxBytes` in `internal/config/cachesize.go` makes the limit 75% of the space free on the cache's filesystem at startup. The cache's own files are not free space, so the limit drops as the cache grows. On an otherwise empty 100 GB disk: the first start allows 75 GB; once the cache holds 75 GB, the next start sees 25 GB free and allows about 19 GB, and eviction deletes about 56 GB of cached images; the start after that allows about 61 GB again. A deployment that restarts on every deploy keeps throwing most of its cache away. `README.md` now tells operators to set `cache_max_bytes`, but the default should not behave like this.
Plan:
- The default counts what the cache already holds as space it may use: 75% of (free space + the bytes the cache already holds), with the 500 MiB floor as now. What the cache holds comes from the cache's own size accounting where the cache is opened (`Cache.UsageBytes` in `internal/imgcache`), not from walking the directories at startup; so the default is worked out there, after the database is open, and logged as now.
- Test first: with a fake free-space probe and a cache already holding N bytes, the default is 75% of (free + N), so a full cache keeps its limit across a restart.
- `README.md`, where it describes the default, says what it counts; the advice to set `cache_max_bytes` for a lasting deployment may stay.
Model: opus-5-5
Built in #188: when cache_max_bytes is omitted, the cache now works out the default when it opens, as 75% of the sum of the free space and what it already holds, at least 500 MiB. The PR body lists what moved and the disclosures.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/pixa/pulls/188: when `cache_max_bytes` is omitted, the cache now works out the default when it opens, as 75% of the sum of the free space and what it already holds, at least 500 MiB. The PR body lists what moved and the disclosures.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found while reviewing #182 (#89). Checked against
nextatbe6c715.When
cache_max_bytesis not set,ComputeDefaultCacheMaxBytesininternal/config/cachesize.gomakes the limit 75% of the space free on the cache's filesystem at startup. The cache's own files are not free space, so the limit drops as the cache grows. On an otherwise empty 100 GB disk: the first start allows 75 GB; once the cache holds 75 GB, the next start sees 25 GB free and allows about 19 GB, and eviction deletes about 56 GB of cached images; the start after that allows about 61 GB again. A deployment that restarts on every deploy keeps throwing most of its cache away.README.mdnow tells operators to setcache_max_bytes, but the default should not behave like this.Plan:
Cache.UsageBytesininternal/imgcache), not from walking the directories at startup; so the default is worked out there, after the database is open, and logged as now.README.md, where it describes the default, says what it counts; the advice to setcache_max_bytesfor a lasting deployment may stay.Model: opus-5-5
Built in #188: when
cache_max_bytesis omitted, the cache now works out the default when it opens, as 75% of the sum of the free space and what it already holds, at least 500 MiB. The PR body lists what moved and the disclosures.Model: opus-5-5