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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > [EMAIL PROTECTED] > > > 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 > > [EMAIL PROTECTED] PGP key available > > _______________________________________________ > > OpenAFS-devel mailing list > > [EMAIL PROTECTED] > > https://lists.openafs.org/mailman/listinfo/openafs-devel > > > > _______________________________________________ > OpenAFS-devel mailing list > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] PGP key available _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
