Date: Sat, 27 Apr 2002 21:57:07 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Brian Candler <B.Candler@pobox.com> Cc: freebsd-fs@freebsd.org, freebsd-net@freebsd.org Subject: Re: NFS clearing attribute cache in nfs_open Message-ID: <Pine.NEB.3.96L.1020427215343.64976B-100000@fledge.watson.org> In-Reply-To: <20020426181535.B2748@linnet.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 26 Apr 2002, Brian Candler wrote:
> I have been tracing some performance problems on diskless systems. In
> particular, the following test program:
>
> perl -e 'for ($i=0;$i<1000;$i++) { open F,"</bin/rm"; $x=<F>; close F;}'
>
> generates 1000 'access' transactions, and hence an exchange of 2000 UDP
> packets, just from repeatedly opening the same file.
Because access control is performed on the server with NFSv3, not the
client, you have to go to the server when you open a file. The attribute
cache caches information for stat(), not for evaluation during open().
Although open() might stat the file (vop_getattr()), that's really not the
same thing. Try instead a stat() rather than open() and see how the
results change in your performance test. Note that an important reason to
invoke the NFS RPC for access during open() is that the client may not
understand the protection semantics of the server. For example, the
server might support ACLs, but the client might not. Or the server might
support another access control model of another sort. The return from
GETATTR is generally just used for file information rendering as of NFSv3,
not actual evaluation.
If you cache data for open()'s, you risk problems during a revocation
operation. Also, you potentially allow opening files that will become
ESTALE, etc. NFSv2/3 isn't really intended to do this sort of caching.
You might want to investigate AFS, since AFS tends to perform operations
on close() rather than open() once a file is in the cache (and has a
"callback" model to invalidate cached files on meta-data changes of this
sort).
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020427215343.64976B-100000>