From owner-freebsd-current Wed Oct 14 09:04:22 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12812 for freebsd-current-outgoing; Wed, 14 Oct 1998 09:04:22 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA12806 for ; Wed, 14 Oct 1998 09:04:21 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id JAA01077; Wed, 14 Oct 1998 09:04:20 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810141604.JAA01077@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Brian Feldman cc: Mike Smith , "Alex G. Bulushev" , Daniel Rock , current@FreeBSD.ORG Subject: Re: -current NFS problem In-reply-to: Your message of "Wed, 14 Oct 1998 11:52:14 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Oct 1998 09:04:20 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Perhaps this could be the problem with NFS "hanging" certain people all > the time? (not the pine thing) The system spending way too much time > inside the kernel transmitting NFS packets.... No. Lack of ACCESS caching makes us slow and eats the network (because we are very good at generating/sending/receiving them). If there's someone out there that wants to work with the very best NFS people in the business to sort out our problems, please let me know. NetApp are keen to see our issues resolved (it will mean less angst for them in the long run, as they have many FreeBSD-using customers). Right now, we are accumulating a bad NFS reputation. 8( > Brian Feldman > > On Wed, 14 Oct 1998, Mike Smith wrote: > > > > another known problem exist for nfsv3 > > > > > > we use www server working over nfs with about 1500000 hits/day > > > it work fine with nfsv2 (load 0.1 - 0.8), but with nfsv3 > > > we see load > 130 and server replay is very slow ... > > > i think this is a bug in fbsd nfsv3 realization, the > > > same scheme with solaris/sparc nfsv3 client/server work > > > without this problems ... > > > > The problem here is almost certainly that we don't cache the results of > > ACCESS RPC calls. There's an outstanding request from NetApp for us to > > address this; their testing indicates that 80% or more of NFS traffic > > generated by FreeBSD systems consists of ACCESS RPC calls. > > > > -- > > \\ Sometimes you're ahead, \\ Mike Smith > > \\ sometimes you're behind. \\ mike@smith.net.au > > \\ The race is long, and in the \\ msmith@freebsd.org > > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-current" in the body of the message > > > > -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message