Date: Thu, 28 Oct 1999 11:04:02 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Matthew Jacob <mjacob@feral.com> Cc: freebsd-current@FreeBSD.ORG Subject: Re: really draggy NFS access in -current? Message-ID: <199910281804.LAA05133@apollo.backplane.com> References: <Pine.BSF.4.10.9910280115530.97297-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910281804.LAA05133>