From owner-freebsd-net Fri Apr 26 16:42:59 2002 Delivered-To: freebsd-net@freebsd.org Received: from mail.allcaps.org (mail.allcaps.org [208.252.245.17]) by hub.freebsd.org (Postfix) with ESMTP id 003E337B41A; Fri, 26 Apr 2002 16:42:54 -0700 (PDT) Received: from mail.allcaps.org (localhost [127.0.0.1]) by mail.allcaps.org (Postfix) with ESMTP id 6C7CC32601; Fri, 26 Apr 2002 16:42:49 -0700 (PDT) Received: from localhost (bsder@localhost) by mail.allcaps.org (8.12.3/8.12.3/Submit) with ESMTP id g3QNgmxo008721; Fri, 26 Apr 2002 16:42:49 -0700 (PDT) X-Authentication-Warning: mail.allcaps.org: bsder owned process doing -bs Date: Fri, 26 Apr 2002 16:42:48 -0700 (PDT) From: "Andrew P. Lentvorski" To: Brian Candler Cc: , Subject: Re: NFS clearing attribute cache in nfs_open In-Reply-To: <20020426181535.B2748@linnet.org> Message-ID: <20020426162442.N8693-100000@mail.allcaps.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 26 Apr 2002, Brian Candler wrote: > perl -e 'for ($i=0;$i<1000;$i++) { open 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 majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message