:ps al on my system shows multiple nfsrcv hangs on processes such as df, ls
:and umount. Without any other characteristic problems, the nfs server
:machine's exports all seemed to be working correctly. However, *one* and
:only one of the mounts somehow went south. 'mount' on the client machine
:shows:
:
:# mount | grep 10.0.0.2
:10.0.0.2:/usr on /f/usr
:10.0.0.2:/devel on /f/devel
:10.0.0.2:/bigfs on bigfs
I assume the hangs are on the client? Not surprising if its a 3.2
system. A whole lot of NFS fixes went in between 3.2 and 3.4 so I
recommend upgrading the client to the latest post 3.4 -stable.
:That's verbatim... The mount was NOT done on bigfs... It was in fact done
:on /f/bigfs. "We have secretly switched this SysAdmin's mountpoint with
I don't know what is going on here, but it kinda sounds like cockpit
trouble somewhere either in the exports line or the client's mount
command.
:The client nfs mounts are mounted intr, yet I still can't send a TERM or
:KILL that these processes will catch.
:
intr is problematic but should basically work. If you are using a TCP
NFS mount intr might not work until the tcp connection itself times out,
but in either case will almost certainly not work if there is a protocol
lockup issue (and there are several in 3.2).
:
:As you see, I haven't had any longevity problems up until now..
:
:Has anything been built into -CURRENT to address these hangs? It has
:plagued many in the past, and continues to do so.
:
: Yours truly,
: Ryan Thompson <[EMAIL PROTECTED]>
Both -current and -stable have various NFS fixes that earlier releases
did not. In general, NFS fixes for the -stable branch have been kept
up to date with the work in -current, but -current ought to have much
better NFS performance then stable.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
