Re: nfs_fscache_key question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

[Linux Resources]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

Powered by Linux