Pierre Tardy wrote:
>
> i don't think getting rid out of the fs makes sense, but having memcache
> be available dynamically as an additional layer sounds fine.
>
> It does make a lot of sense for me as I have a high performance network,
> which is faster than local harddrive. So I would insist on keeping an
> option for memcached only.
Both features could be kept.
The "memccached" layer is basically the same (I extended it a bit,
and changed the API a little...) and so is your memcached format.
I suppose you could use our memcached with just a small disk cache,
but you'd get a lot of (unnecessary) writes and cache cleanups ?
IIRC, your manifests (and headers) were still using the local drive.
The option to switch the to_cache/from_cache can be made available
separately, like it was in your PR. But it can use another config ?
Probably needs some updating and refactoring, and it would be nice
to try and keep the code duplication between them to a minimum...
i.e. between the current filesystem code and the memcached code
I can make an attempt to merge them, or if you want to do it...
To add a config like "memcached_only", next to "memcached_conf" ?
If you have a single server, then *neither* option makes any sense.
So it all depends on the setup, and needs to benchmarked further...
I had also added a "readonly" flag, for builds with lots of misses.
It's common to have a shared set of base files, and then with some
local alterations to those... So you would have a "blessed" build
filling up the memcached, and then individual builds based on that
would reuse objects if available but not add their one-offs to it.
The variant shared on NFS would just use CCACHE_READONLY for this.
/Anders
___
ccache mailing list
ccache@lists.samba.org
https://lists.samba.org/mailman/listinfo/ccache
