#2 is a very viable option and could be implemented relatively easily. Here is my proposal. Do not attempt to write full objects into the SSD, instead use it like the RAM cache as a fragment cache. The semantics of a fragment cache are much easier (i.e. just a simple hash table rather than having to ensure that all the fragments of an object are present and deleted together, as well as handling the HTTP header vector and groups of objects).
Leverage the existing index and directory code for the hash table for the SSD. On a fragment hit on disk, write to the SSD. Leave the RAM cache alone. If you write to the RAM cache for every write you will blow it out and it will be completely and utterly useless. You might as well throw it away. Unless the hot set that fits in RAM (and hence no need for a SSD or HD at all) and the RAM cache will get a 0% hit rate. There is a "hit evacuate" feature which may or may not be fully implemented which already has some of the logic... I"ll look into that. john On Mon, Mar 14, 2011 at 8:06 PM, 张练 <[email protected]> wrote: > In https://cwiki.apache.org/TS/ssdsupport.html, we proposed our > demands. > In irc log jplevyakg proposed three ways for supporting ssd cache. > 1) attach to the RAM cache to store the objects. That would be lower > CPU and would lean hard on the SSD and would use RAM to get a decent > replacement policy 2) attach to the disk as a front end cache. Again lower > CPU but use less RAM and have a poorer replacement policy. Or 3) go for > full priority queue, best replacement policy, most flexibly, but also the > most work and potentially use more CPU and a go > I was thinking the second option, i wanna select ssd as a transition > cache in sata and ram cache. > 1) When an user request arrived, ts first find it in ram cache, if not > hit, then ssd, and then sata. > 2) When the request was hit in ram cache or ssd, then return the object > to the user. When the request was hit in sata, then write it to ram cache > following the existing way, at the same time write it to ssd also. When the > request was not hit in all the cache, then the request was send to origin > server, and write the object back to sata.(Because our cache hierachy was > 10G ram cache+100G ssd+1TB sata, so write request both in ram cache and ssd > waste at most 10% percent storage) > I reviewed the Part structure, and i think i can use Part for supporting > ssd cache. I wanna keep a special Part member in Cache, and when Cache find > an object, it first find it in ram cache, and if not hit, then find it in > this special Part member, and then the CacheHostTable member. Because i > don't wanna ts do two asynchronous read, so i wanna find the right Part and > do only one read. If not so, i thought there maybe two asynchronous read: > first find in ssd cache, and if false, go to sata. This will also change > the > logic of do_cache_open_read and state_cache_open_read in HttpCacheSM. > I have seen the codes of iocore/cache for 2 weeks, but i think if i want > to understand it fully, i need another serveral weeks based on some help. > If > you have a better scheme, please tell me. Right now i have to find the fast > way to support ssd asap, because we wanna to put ATS to online usage. I > have > not seen the codes related with partition.config and hosting.config, and i > think if let ssd cache works with partition.config, then another more work > will be done, that will delay our plan. But the best thing i wanna do is to > implement it in an general patch for others' usage, so i wanna find a > better > scheme, and do some work for current demands, and later, complete another > more demands. > > -- > Best regards, > Lian Zhang >
