From: Peter Staubach (staubach@nyday.eng.sun.com)
Date: 06/10/99-11:29:44 AM Z
Date: Thu, 10 Jun 1999 09:29:44 -0700 (PDT) From: Peter Staubach <staubach@nyday.eng.sun.com> Message-Id: <199906101629.JAA70153@nyday.eng.sun.com> Subject: RE: Some caching questions > > > > > > My other caching question has to do with caching of > > directories. Are > > > there any v3 clients out there that cache directories other > > than in the > > > normal name cache sense of caching name-to-vnode or name-to-handle > > > mappings for lookups, etc. that have succeeded. Specifically, does > > > anyone: > > > > > > Satisfy readdir requests without doing an rpc > > > > > > Caching the non-existence of files (unsuccessful lookups). > > > > > > If so, how and when is such caching invalidated and what > > has the experience > > > been? > > > > > > > The Solaris NFS client caches the responses from NFS Version > > 2 READDIR, > > NFS Version 3 READDIR, and NFS Version 3 READDIRPLUS operations. This > > cache is managed using the standard attribute timeout mechanism. This > > seems to work pretty well, but only helps with getdents(2) calls and > > not lookups. > > Does this get flushed somehow if a LOOKUP failure happens which is > inconsistent with it. I know nfs caching is rife which inconsistencies > but the following might be particularly annoying: > > mysys# ls > a b c > mysis# ls -l a > a not found > mysys# ls > a b c > Yup, the readir response cache gets managed in the same fashion as the page cache. When the directory is determined to be modified, then the readdir response cache is flushed. If even the client itself causes the directory to be modified, the readdir response cache is flushed. There is no way for the client to be able to tell how the server manages its directories, so the safe thing to do was to flush whenever there was a question. > > > > The Solaris NFS client also caches the non-existence of files, using > > the DNLC. These cache entries are validated using over the wire > > calls. Thus, if a negative entry is encountered during the lookup > > process, it is validated immediately with an over the wire GETATTR > > call. It is bad to tell an application that a file does not > > exist when > > it does because the application would have no way to recover. (It is > > less bad to tell an application that a file does exist when > > it does not > > because the application can detect this and recover.) The tradeoff > > made here was to trade a (usually) unsuccessful over the wire LOOKUP > > for a GETATTR. The GETATTR is (mostly) always cheaper than an > > unsuccessful LOOKUP since LOOKUP, at least in the NFS Version 3 > > implementation, returns attributes. > > I don't understand this. If you do a GETATTR on the directory > and find out that it's changed, then you have do a (mostly) unsuccessful > LOOKUP. Given the (sort of) fixed overhead of setting up and actually > issuing/responding to an RPC, is GETATTR really that much faster than > an unsuccessful LOOKUP, given that some fraction of the time you are > going to have to do both? > The time savings is spent on the server. On file systems such as ufs, an unsuccessful lookup requires a search of the entire directory. A search of a large ufs directory can take quite a long time, compared to the cost of a GETATTR. Other file system implementations have addressed this problem, but there are still many file systems on servers out there that suffer from this problem. Anyway, I can't really state that the negative caching has been a win or not. My guess is yes, but since we have no reasonable way to measure the client, there isn't a way to objectively tell. ps
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:12 AM Z CST