From owner-freebsd-current Sat Aug 21 19:33:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id CAC7014EC0; Sat, 21 Aug 1999 19:33:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA75644; Sat, 21 Aug 1999 19:32:47 -0700 (PDT) (envelope-from dillon) Date: Sat, 21 Aug 1999 19:32:47 -0700 (PDT) From: Matthew Dillon Message-Id: <199908220232.TAA75644@apollo.backplane.com> To: Doug Cc: "John S. Dyson" , Alfred Perlstein , Eivind Eklund , Peter Wemm , current@FreeBSD.ORG Subject: Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h) References: <199908211156.GAA20231@dyson.iquest.net.> <199908211649.JAA73759@apollo.backplane.com> <37BF4420.452C5076@gorean.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Does anyone know why our NFS clients are sending a separate RPC for each :> 8K buffer? If the dirty space is contiguous across a number of buffers :> we should be able to send a *SINGLE* commit rpc to the server. That would :> greatly reduce system overhead on both the client and server when writing :... :ASAP. The last hurdle (seemingly) on my big project at work that I've been :bugging so many of you about is the fact that FreeBSD NFS client writing to :Sun NFS server is just DOG slow. I did some pretty extensive testing on :this and couldn't come up with any client option twidding that made any :difference, except increasing wsize to 16k, which got me about 10%, but it :was still very slow. This is on a -current system from around the tenth of :August. : :Doug Well, this is definitely optimization I would love to do, but first I need to know whether it's legal to combine NFSv3 commit RPCs. If there are any NFS experts out there, I'm all ears! This would get rid of half the rpc transaction traffic for sequential writes. My read of the code seems to infer that it *is* legal. There's another optimization which was submitted to me which gets rid half the stat rpcs which I haven't even had time to look at yet. These particular optimizations would not reduce aggregate network bandwidth but it would cut the cpu load on the client and server in half for operations in question. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message