feature request: --no-cache equivalent

[borkd]

It would be super helpful if rustic would gain a --no-cache equivalent for its commands. Caching index and snapshots is not a big deal, but data is the source of problems which prevents me from troubleshooting #48 further.

Why? Caching makes sense when one works with a slow or expensive backend. When reads are cheap, as it might be the case of local filesystem access, implementing caching that actually speeds things up even further at scale is a difficult ask.

Local storage is performant enough in terms of performance and capacity to forego caching completely for the repo referenced in #48. A --no-cache mode would reduce CPU overhead and, more importantly, significantly reduce flash wear on every check or prune.

[borkd]

I see existing cache commits are fairly recent, and indicate "no-cache" might be in the works

rustic/src/commands/mod.rs

Line 54 in 6ed332c

#[clap(long, parse(from_os_str), conflicts_with = "no-cache")]

[aawsome]

With the merge of #33 there already is a --no-cache implemented.

Might be that that merging #33 without noticing you messed up your test - sorry for this.

In rustic, I implemented the following logic:

• if you don't specify --no-cache either a restic cache dir is used or a rustic cache dir is used (and created if it doesn't exist)
• if you specify --no-cache an a cache dir (restic or rustic) for this repo exists, use that
• if you specify --no-cache an no cache dir (restic or rustic) for this repo exists, don't use a cache

So I think the only irritation was that you (accidentially) did run rustic with #33 included but without specifying --no-cache once. Then for further runs --no-cache doesn't have an effect.

You can simply remove the dir that is shown at using cache at <DIR> and --no-cache will work as intended.

[aawsome]

If you think that the current logic is too irritating, please tell me. This was just the (maybe stupid) idea to check for existing cache dirs and if one exists, always use it!

[borkd]

I saw merges being done in between my issues and browsed the code way too briefly. Neither rustic check --help and rustic prune --help had references to (no) cache use, so I figured this feature might be merged but not enabled by default.

Possible improvement: I have discovered that --no-cache only appears in the context of main rustic command, as in rustic help or rustic --help, and is not shown anywhere else. While this matches the scope of this mode of operation, better UX would be to produce all possibly relevant options in the context of command where --help was mixed in. Starting with global rustic settings, through options specific to requested action, all the way to any future backend stuff.

If you think that the current logic is too irritating, please tell me. This was just the (maybe stupid) idea to check for existing cache dirs and if one exists, always use it!

The choice to quietly reuse/hijack restic caches gave me a brief pause. While I liked the idea - this makes end-to-end cross-validation between restic and rustic possible while halving the footprint on disk, sharing caches between "production" (whatever that means for the user of backup software) and possibly unstable development should be their conscious choice. To that end I propose --share-with-restic flag (false by default), or a --no-cache-sharing if rustic retains current logic to hijack caches opportunistically by default. --no-cache (false by default) of course implies no caching at all.

[aawsome]

Thank you very much for your feedback!

About UX I opened #50.

For the caching options, I'll change --no-cache to never use a cache and only use rustic cache dir by default. If anyone wants to reuse a restic cache dir, it is always possible to use --cache-dir ~/.cache/restic or similar.