Name Lookup Cache: BDS vs SunOS (re-try)

[Mike Cherepov]

I cross-posted to comp.sys.sun being unaware of its moderated status.
Apologies if you saw this already or if you bump into it later...

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 that 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 at harvard.harvard.edu