Abhishek Kulkarni <abbyzcool@xxxxxxxxx> wrote: > Thanks, David. That clears it up. However, when is ->get_key() called > by fscache for an index cookie? I see that it gets called from within > cachefiles when allocating a new object of non-index type. ->get_key() is called by cachefiles_alloc_object() for all types of object. This is then cached in object->lookup_data until cachefiles_lookup_complete() is called. > In my case, I am generating a uniquifier in ->get_cookie() and > ->get_key() just returns back this uniquifier. But, I don't see ->get_key() > being called any time during object allocation. Consequently, for every > mount I get a new index into the cache. Ummm... ->get_cookie()? What's that? From what are you generating the uniquifier? > My understanding of how it works was that fscache_acquire_cookie() > calls ->get_key() and compares it with the keys of the existing index > cookies and returns the cookie which has the same key or creates > a new one if it doesn't. Not exactly. The comparison is farmed off to the backend to perform - probably cachefiles - because the backend is responsible for maintaining the persistent data. Now, index objects are lazily instantiated - they are only looked up or created when a non-index object in them is requested. This is because indices may exist in multiple caches, but non-index objects are restricted to a single cache (this simplifies things). So until we have a non-index object to look up, we don't know which cache we are going to be dealing with, so we don't bother setting up the indices till that point. David -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cachefs
