Thank you, John. The Part keeps two Directory, it explains them as Directory A and Directory B, each one contain a header of type PartHeaderFooter, a group of Dir, and a footer of type PartHeaderFooter. I can't understand why Part need to keep two Directories? What is each one's usage?
On Tue, Mar 15, 2011 at 11:41 PM, John Plevyak <jplev...@acm.org> wrote: > #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, 张练 <wahu0315...@gmail.com> 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 > > > -- Best regards, Lian Zhang
