On Fri, 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.
Hi, I've just tried to increase cache too far so I've run out of inodes n a partition. afsd did not die, it just continued to create next cachefile and so on, each attempt resulted in error 28. I dont have the log saved, but inspecting kern.log I see that afsd at least logged this error when started up next time with that incomplete cache directory structure: Jan 12 19:43:29 calomys kernel: Starting AFS cache scan...<2>EXT3-fs error (device sd(8,3)) in ext3_new_inode: error 28 Jan 12 19:43:29 calomys kernel: EXT3-fs error (device sd(8,3)) in ext3_new_inode: error 28 That was on linux 2.4.19 i686, EXT3 partition. The size of cache was 1024000000 I believe. What is actually the maximum size of afs cache? We would like to get several files above 800MB cached at once in the cache. Any recommendations? Ah, so far I've been talking about Linux, but most of the client machines will be Tru64 5.1A, so running transarc client code. As far as I understand, we don't need licenses for clients, right? ;) > 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 ? -- Martin Mokrejs <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs MIPS / Institute for Bioinformatics <http://mips.gsf.de> GSF - National Research Center for Environment and Health Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany tel.: +49-89-3187 3683 , fax: +49-89-3187 3585 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
