Cache usage after prune

[gurkan]

@MichaelEischer

What do you expect to learn from additional cache related statistics?

I thought seeing some kind of added/removed/total size information regarding caches might be useful.

@MichaelEischer

It could be possible to remove some of the files from the cache earlier on, before they are actually deleted from the repository, but that makes the code more complex.

But those files are already removed from the repository. Timeline is:

• Backup: fills cache
• Backup: uses cache
• Prune is done (triggered from another host)
• Backup: re-fills the cache first, then removed the pruned elements

I thought if our entrance point is “snapshots”, after getting the latest ones maybe we’d know which indexes (&data) to wipe before pulling new ones. But yes, even this assumption would add complexity

@MichaelEischer

And it might be necessary to cache the old and new data to allow resuming from an interrupted prune run, so the additional space should be available anyways.

Hmm correct, I don’t trigger prune from these clients, so I overlooked this.

Problem is: A big enough repo is causing 4.5GB cache folder on these hosts, considering this “double usage” after prunes, it adds up. I’ll need to think something else. Afaik there is no practical way to limit cache folder, and I suspect restic won’t react good if I put the cache on a limited-size separate filesystem etc.

Maybe I need to manually wipe the cache folder after a prune flag is set somewhere.