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