[OpenAFS-devel] cached data on disk

Narasimhan A V venkatar@cae.wisc.edu
Sun, 8 Dec 2002 22:21:08 -0600 (CST)


Hi,
	okay. If the cache truncation daemon does not run and the cache is
full then is it true that no new blocks will be alloted? In other words
does this mean that every new chunk will be fetched from the server?
I am doing some measurements with respect to the cache manager and the
test is somewhat like this.

I sequentially read a file which will surely overflow the cache. My cache
size is 100 MB. I try to read 120 MB. If i read these 120 mega bytes two
times consecutively in a loop the time taken is much longer than the time
taken when i read these 120 Mbytes with a time gap in between. Also i
check the
size of the cache directory and i see that it remains more than the 100 MB
in the former case. I was wondering if this is because the cache is
full and the truncation is not done before i read it again.

Thanks,
Narasimhan



On 6 Dec 2002, Derek Atkins wrote:

> Yes, the disk cache uses an LRU algorithm to decide when to throw data
> out of the cache.  However, the cache size is not a hard limit.  It is
> possible to actually over-flow your cache partition before the truncation
> algorithm hits.  In that case, you may lose data or crash AFS.
>
> For implementation details you can look at src/afs/afs_dcache.c -- I think
> that's where the LRU code is.
>
> -derek
>
> Narasimhan A V <venkatar@cae.wisc.edu> writes:
>
> > Hello,
> >         what is the replacement policy used by the cache manager when the
> > disk cache overflows. I know that the in memory dcache entries are
> > maintained in a LRU queue. Is it LRU for the cached data on disk too.
> > If it is how is it implemented ?
> >
> >
> > Thanks,
> > Narasimhan
> >
> >
> > _______________________________________________
> > OpenAFS-devel mailing list
> > OpenAFS-devel@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-devel
>
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord@MIT.EDU                        PGP key available
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>