cache-dir/max-cache-size with local disk back-end

[GertyP]

I'd like to confirm (or clarify) my understanding of the rudolfs cache options: If I have rudolfs running (using 'local disk' back-end) on some server on a LAN, used by other machines on the network, I'd assume there's no good reason to configure the rudolfs server to dedicate more of the same local disk storage (via the --cache-dir and --max-cache-size options) to caching and duplicating the same files that already exist on the same local disk. I.e. the rudolfs server's cache only really makes sense in conjunction with non-local back-ends.

Perhaps the caching mechanism is (or may be in the future) a suitable place to employ compression that might avoid complications with compression applied in back-ends (I don't have a good grasp of those considerations), which might mean that caching might still make sense even with local disk storage back-end.

Is it the case that it's currently pointless to use caching with the local disk back-end and if so, should (and does) rudolfs just ignore the options and disable caching if the 'local' back-end option is specified?

[jasonwhite]

Your understanding is correct, a cache is pointless and takes up unnecessary space when serving files off of the local disk. However, a case where it can be useful is if you are serving off of a network file system (e.g., from a NAS) or from a FUSE file system (e.g., sshfs). Then, if the network/FUSE file system is slow, using a local cache could potentially speed it up.

You prompted me to go back and look through the code for the local disk backend code and it looks like I never actually implemented caching for it(!). So, even if you specified --cache-dir=<DIR> with the local disk backend, it won't (currently) use it.

[jasonwhite]

If/when compression is implemented, then hopefully the payload doesn't need to be decompressed before sending it to the client and a cache would still be pointless. (IIRC the gitlfs client can handle gzipped LFS objects.)