From owner-cvs-all  Sun Nov  1 18:36:16 1998
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id SAA17503
          for cvs-all-outgoing; Sun, 1 Nov 1998 18:36:16 -0800 (PST)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA17497;
          Sun, 1 Nov 1998 18:36:15 -0800 (PST)
          (envelope-from peter@FreeBSD.org)
From: Peter Wemm <peter@FreeBSD.ORG>
Received: (from peter@localhost)
	by freefall.freebsd.org (8.8.8/8.8.5) id SAA00545;
	Sun, 1 Nov 1998 18:36:17 -0800 (PST)
Date: Sun, 1 Nov 1998 18:36:17 -0800 (PST)
Message-Id: <199811020236.SAA00545@freefall.freebsd.org>
To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject: cvs commit: src/sys/kern vfs_vnops.c
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

peter       1998/11/01 18:36:17 PST

  Modified files:
    sys/kern             vfs_vnops.c 
  Log:
  Only do one VOP_ACCESS() per open() instead of two.  This should reduce
  the NFSv3 ACCESS RPC problems a little for busy clients that do a lot of
  open/close.  The nfs code could probably cache the results, but I'm not
  sure whether this would be legal or useful.  The problem is that with
  a CPU farm, on each open there would be a lookup, getattr then access RPC
  then the read/write RPC activity.  Caching the access results probably
  isn't going to help much if the clients access lots of files.  Having the
  nfs_access() routine interpret the getattr results is a bit of a hack, but
  it's how NFSv2 is done and it might be OK for a mount attribute for v3.
  
  Revision  Changes    Path
  1.60      +9 -8      src/sys/kern/vfs_vnops.c

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message