: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
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
