From owner-freebsd-current Thu Oct 15 21:47:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA08287 for freebsd-current-outgoing; Thu, 15 Oct 1998 21:47:00 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA08280 for ; Thu, 15 Oct 1998 21:46:57 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.1/8.9.1) with SMTP id AAA28703; Fri, 16 Oct 1998 00:46:30 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA15385; Fri, 16 Oct 1998 00:46:30 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id AAA23559; Fri, 16 Oct 1998 00:46:29 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199810160446.AAA23559@bb01f39.unx.sas.com> Subject: Re: -current NFS problem In-Reply-To: From Mike Smith at "Oct 14, 98 09:04:20 am" To: mike@smith.net.au (Mike Smith) Date: Fri, 16 Oct 1998 00:46:29 -0400 (EDT) Cc: freebsd-current@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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( > ... deleted for brevity... Hi, I have 50 266 Mhz pc's clustered around 3 netapp F630 Filers used as compile servers for an in-house distributed make facility. 85% of the traffic to the netapp(s) 'was' due to access calls. I do not recommend it for public consumption, but the following patch reduces the access overhead to less than 20%. diff nfs_vnops.c /nfs/locutus/usr/src/sys/nfs 273c273 < int v3 = NFS_ISV3(vp); --- > int v3 = 0; /* NFS_ISV3(vp); */ ie: tell the nfs_access() function we're always version 2, even though we're actually connected via 3. The side effect of this patch is to delay file access errors, but this is not a real problem in our environment. FWIW: currently, 28 pc's connected to 1 F630 netapp delivered the following performance (not a controlled test, just an overnight job): >>>STAT: 3149 .o : avg time 00:02 : avg speed 520/minute : 0 failed. ie: 6 minutes to compile 3149 files. Our usage of the filers is sequential read of c/h files, and then sequential write of the .o file. We do not do mmap'd or random access i/o and thus have seen no problems such as those reported on -current. Just my 0.02 John ps: BTW, I cannot amd mount the filers due to a problem with GARBAGE_ARGS being returned from clnt_call() in amfs_host.c\fetch_fhandle() regardless of whether I force a V2 or V3 mount protocol. This is a 'random' error which I can get to occurr approximately 1 out of 10 mounts. We wrote a small shell script to mount/umount the filers and interfaced this with amd via the type=program statement (being tested). So far, this has yet to fail... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message