On Fri, 26 Apr 2002, Brian Candler wrote:
> perl -e 'for ($i=0;$i<1000;$i++) { open F,"</bin/rm"; $x=<F>; close F;}'
I will assume that you wrote this *only* to prove the point. However, if
you are using NFS, you need to check the status of both open *and* close.
Otherwise you are likely to start breeding *very* insidious bugs.
> ... Could it safely be made less restrictive, e.g. don't
> clear the cache when opening a file for read?
In a word, no. Why couldn't the sysadmin be running "make installworld"
on the NFS server while you're running that program? By definition, for
better or worse, NFS is "stateless". The only way in which NFS can know
that your file hasn't changed (been deleted, renamed, etc) is to make that
round trip to the server. Sorry.
> I think there are some
> potentially large performance gains for diskless server clusters, where the
> same file is being repeatedly exec()'d.
Yes, as long as you are willing to risk invalid data. If you are really
into clusters with low-latency, you might want to look into something like
NFS V4 (Is anybody working on that on FreeBSD, anymore?), AFS, CODA, or
something more specialized. Those networked filesystems have a
bidrectional characteristic and cached state protocols so that they can
minimize communication.
-a
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
