[OpenAFS-devel] Re: Some doubts with Kernel Module data structures

[Andrew Deason]

On Sat, 22 May 2010 12:34:06 -0400 (EDT)
"Matt W. Benjamin" <matt@linuxbox.com> wrote:

> ----- "Sanket Agarwal" <sanket@sanketagarwal.com> wrote:
> 
> > I am looking into the core data structures of OpenAFS kernel module
> > for clients, of which I find that struct dcache and struct fcache
> > will be most important. I wish to ask you a few questions here:
> 
> struct vcache

I found this a bit confusing when I first looked at it, so a little more
info... a vnode is the OS' filesystem-agnostic in-memory representation
of a file. A vcache is the OpenAFS module's in-memory representation of
a file. You can get a vnode from a vcache and a vcache from an AFS vnode
a couple of different ways, depending on what the client OS is. That's
what AFSTOV and VTOAFS are for.

> > and is this chunk size same as that of Page size of pages in the
> > memory(which the kernel will ultimately load as pages in the
> > memory).
> 
> no, typically a chunk is 64k, but you can set an alternate chunk size
> when the cm is started, see AFSD(8)

Default chunk sizes for a disk cache ranges from 256K to 1M, depending
on the size of the cache. For caches smaller than around 500M, the
chunksize is 256K; smaller than 1G and it's 512K. Larger and it's 1M.

For memcache the default is 8k.

> > 3. What is the role played by the structure struct fcache, what does
> > it point to ?
> 
> I'm not a dcache expert, but cribbing from the code, it looks as if
> an fcache is involved with representing chunks in the cm's persistent
> file cache
> 
> > 4. I see that dcache is stored in the memory but fcache is disk
> > saved on disk( where , along with the afs cache ?) And why such a
> > decision.

The CacheItems file is made up of a bunch of 'struct fcache's (each one
representing a chunk, as Matt says). We need to save some information
about each chunk to disk, so we can find them again. So when a client
restarts and asks for file X chunk Y, we can find where that chunk is in
the cache.

-- 
Andrew Deason
adeason@sinenomine.net