🚀 go-pugleaf

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