From owner-freebsd-fs@FreeBSD.ORG Fri Aug 10 15:28:21 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B823D16A46C for ; Fri, 10 Aug 2007 15:28:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from ccshst09.cs.uoguelph.ca (ccshst09.cs.uoguelph.ca [131.104.94.206]) by mx1.freebsd.org (Postfix) with ESMTP id 630FD13C4E8 for ; Fri, 10 Aug 2007 15:28:21 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.96.170]) by ccshst09.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id l7AFSGrx002293 for ; Fri, 10 Aug 2007 11:28:19 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id l7AFXMW27807 for ; Fri, 10 Aug 2007 11:33:22 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 10 Aug 2007 11:33:22 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher To: freebsd-fs@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 131.104.94.206 Subject: multiplexing TCP sockets in the NFS client X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2007 15:28:21 -0000 Long long ago, I felt it might be better to use a separate TCP socket for each mount to the same server. The argument was along the lines of: Some mounts might be much busier than others and, as such, the separate TCP socket would provide feedback to the client w.r.t. load on that mount. The assumption w.r.t. busier mount points tacitly assumed separate disks with some disks experiencing heavy I/O loads. It seems to me that these days, what with SANs, RAIDs, GEOM,... that a mount point probably isn't going to reflect a different disk subsystem so much as an administrative boundary. Also, it's not obvious that the feedback argument is relevant anyhow, since clients will still receive replies when the server gets around to doing the RPC, in any case. So, I'm thinking that it might be better to change the client code so that it shares one TCP connection between all mounts to the same server. This reduces the number of TCP connections (possibly an issue if clients use an automounter to do a lot of mounts). It might also help w.r.t transport performance by increasing the volume of data being transferred on the TCP connection? (I don't know enough about current TCP stacks to know if this is the case or not?) Any comments? rick