[OpenAFS-devel] cached data on disk

[Derek Atkins]

Yes, I suspect that your analysis is correct -- the truncation daemon
doesn't get the chance to truncate the cache between rapid reads.

-derek

Narasimhan A V <venkatar@cae.wisc.edu> writes:

> 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
> >
> 
> _______________________________________________
> 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