Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!ucbarpa.Berkeley.EDU!edward
From: edward@ucbarpa.Berkeley.EDU (Edward Wang)
Newsgroups: comp.unix.wizards
Subject: Re: Directory compression
Keywords: 4.3BSD
Message-ID: <38254@ucbvax.BERKELEY.EDU>
Date: 19 Aug 90 09:44:18 GMT
References: <7913@lynx.UUCP> <26078@mimsy.umd.edu>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: edward@ucbarpa.Berkeley.EDU.UUCP (Edward Wang)
Distribution: na
Organization: University of California, Berkeley
Lines: 17

In article <26078@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
>The logic is this:  if we are creating a new entry (CREATE or RENAME
>operations), a cache lookup will only tell us that we cannot proceed,
>not that we can.  This is rarely helpful (the typical case is that we
>can proceed, and looking in the cache will just mean spending some time
>only to get a `no information' result).  Otherwise (for a LOOKUP or a
>DELETE) we can use the cache; however, profiles gathered on ucbvax
>showed that cacheing DELETE operations was not a win, so it is not
>done.

This brings up a related question.  A result of a study I did
a while ago is that failed lookups often repeat (stats of mail boxes,
for example), and caching this information brings the hit rate
(cache hit / total number of lookups) up quite a bit.
(The cache would contain files known not to exist.)
My impression is that BSD does not do this.
Does anyone here know why?