cher@ksr.com (Mike Cherepov) (09/07/89)
The BSD book (Leffler, et al) mentions several reasons why the name-to-inode translation cache is better off ensuring hit validity by unique id numbers (they call it "capability"), rather then by hard references (bumping up the inode count if the cache holds a reference). Among their reasons are the impossibility of verifying the sole use of a file and that the size of the cache is limited by the size of the inode table. Sun decided on exactly the opposite: their name lookup cache does hold hard references. In addition to the disadvantages mentioned, the Sun implementation has a deadlock problem: the cache keeps its own LRU and will start inactivating inodes as it runs out of space. Looks like it may try to inactivate (and lock for that purpose) the parent of the inode it tries to add to cache, and, therefore, deadlock with the lookup routines which lock inodes from root to leaves. The benefits from the name translation cache's LRU (whose hard references can hold inodes) seem small, because the inode free list does the same thing. Since there do not seem to be any appreciable gains, I wonder what prompted Sun to change the BSD scheme. My only plausible guess is that the NFS stuff required this, but I don't see why: the unique capability numbers used by BSD could just as well have been used with the vnodes. Can somebody familiar with Sun's implementation and reasoning comment? Mike Cherepov (617) 895-9400 x507 Kendall Square Research harvard!ksr!cher or ksr!cher@harvard.harvard.edu