On 02/21/2014 06:29 AM, Nikolai Gorchilov wrote: > On Fri, Feb 21, 2014 at 7:34 AM, Alex Rousskov wrote: >> With aufs, kid2 does not know that kid1 already has the object in its >> kid1-specific cache_dir because aufs store is not SMP-aware: You are >> forced to use kid-specific aufs cache_dirs to avoid cache corruption. > Unfortunately yes :) >> Besides making aufs SMP-aware, it would be possible to reduce such >> duplicate storage by hacking the shared memory cache index to keep >> information about the cache_dir holding the object (if any), but it is >> not easy to do, it will not work reliably, and you will still face >> similar problems when the object is purged from the memory cache or is >> never stored there. > Seems switching shared_memory to off is the only "stable" solution for now. I am not sure which problem you are trying to solve by switching the shared memory cache off, but doing so will not decrease the amount of duplication in kid-specific caches. In fact, it will _add_ memory cache duplication to the existing disk cache duplication. Said that, I personally have not analyzed how a shared memory cache interacts with non-SMP stores. It is possible that the two are not compatible in some ways. I have not heard of any such incompatibilities yet, but disabling the shared memory cache will bring you closer to a well-understood and supported (albeit inefficient) SMP configuration. > Moving to large rock is also an option, but I'm afraid to do so due to > the heavy trunk refactoring nowadays. How feasible is back-porting > only the bare minimum for large rock support from trunk to 3.4 in your > opinion? Large rock support required significant changes to the core Store API. It would be impossible to backport Large Rock without backporting those changes as well. It will be a significant effort, expanding well beyond adding a new storage module (or updating an old one). FWIW, I do not recommend starting such a project, especially without getting a Squid Project approval on v3.4 inclusion of the results first. I am not sure I would support such an approval personally (but I would probably not block it either). IMHO, if you need Large Rock, the best way forward is to make trunk-based code stable enough for your deployment needs. Yes, there will be some pains along the way, but that approach may require smaller overall effort with larger overall payoff than porting Large Rock back to v3.4. Do keep in mind that v3.4 did not quite work for you either! In my experience, virtually any new deployment in a demanding environment and/or with an admin that looks for suboptimal behavior is likely to require some fixes/workarounds/improvements. Thus, if you are willing to do the dance and want cutting-edge features, backporting is often an inferior solution, especially when it comes to large features affecting Squid core. $0.02, Alex.