On Thu, Aug 20, 2009 at 4:31 AM, David Howells <dhowells@xxxxxxxxxx> wrote: > Abhishek Kulkarni <abbyzcool@xxxxxxxxx> wrote: > > > I was reading through the NFS fscache code (nfs/fscache.[ch] & > > nfs/fscache-index.c specifically) and I found that nfs_fscache_key > > stores a lot of information about the superblock which probably looks > > redundant. IOW, I don't see it being used anywhere. Is it just to make > > sure that the key is cooked into something unique? > > It is stored on disk. nfs_super_get_key() passes it to fscache, which then > uses it as the lookup key into the cache for a superblock (the cache is > persistent). > 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. 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. 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. Thanks again, Abhishek > > It became necessary, unfortunately, to distinguish the caching for NFS > superblocks based on their connection parameters, as NFS superblocks are > distinguished in this manner. > > David > > -- > Linux-cachefs mailing list > Linux-cachefs@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cachefs > -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cachefs
