From owner-freebsd-current Thu Oct 28 11: 8:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3B48514BDD for ; Thu, 28 Oct 1999 11:08:24 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id LAA22092; Thu, 28 Oct 1999 11:08:20 -0700 Date: Thu, 28 Oct 1999 11:08:24 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG Subject: Re: really draggy NFS access in -current? In-Reply-To: <199910281804.LAA05133@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hmm. Could be. That's a good thing to try. The connection is a Full Duplex 100BaseT to a 3com switch (both alpha/freebsd && Solaris) so what you suggest Just Didn't Occur To Me (tm). Thanks.... On Thu, 28 Oct 1999, Matthew Dillon wrote: > :Okay- I went home and left a cvs update going on /usr/src - reading from > :a local CVSUP repository NFS mounted on /home/ncvs. The server is a > :Sun SS1000 Solaris 2.6 box. 6 hours later, the cvs update is still chugging > :slowly along- top shows cvs as: > : > : PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND > : 275 mjacob 2 0 8704K 7616K sbwait 1:28 1.90% 1.90% cvs > : > :most of the time. Just to check that something wasn't broken for da5, > :I did a test dd writing to a file just now and it happily munched along > :at 4MB/s. > : > :The filesystem *is* a fat block fs: > : > : a: 4304896 0 4.2BSD 8192 32768 16 # (Cyl. 0 - 267*) > : > :I suppose the blockage could be at the ufs end... Anyone have a pointer > :as to what try to narrow this down- mainly to save me the trouble of > :actually thinking about it (got a lot else on mind)? Unacceptably bad > :something or others here..... > > This kinda sounds like packet loss to me, causing the NFS link to > back off. This would be true for both a udp or tcp nfs mount, but > tcp tends to be more sensitive to packet loss. > > You should be able to tell by ktrace'ing the running cvs and then > kdump -R'ing the resulting ktrace.out file to see if weird delays are > occuring on nfs-related syscalls. > > -Matt > Matthew Dillon > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message