Re: Annoying nfsrcv hangs
:> 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. : :Performance = transfer rates and latency? Or just generalized stability? :I haven't had the time to watch -CURRENT all that closely, but I'll be :happy when some of the new functionality becomes -STABLE. : :Thanks for the reply, :- Ryan There were a few bugs that we couldn't fix in stable, mainly related to localhost NFS mounts and garbage showing up past EOF when mmap()ing a file over NFS. Normal use of NFS will not hit the bugs. -Current fixes those bugs plus adds some major performance optimizations. I'd stick with 3.x for the moment. Move to 4.x after 4.1 is released. -Matt Matthew Dillon <[EMAIL PROTECTED]> :-- : Ryan Thompson <[EMAIL PROTECTED]> : Systems Administrator, Accounts : Phone: +1 (306) 664-1161 : : SaskNow Technologies http://www.sasknow.com : #106-380 3120 8th St E Saskatoon, SK S7H 0W2 : : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with "unsubscribe freebsd-hackers" in the body of the message : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Annoying nfsrcv hangs
Matthew Dillon wrote to Ryan Thompson: > :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 > : [...] > > 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. Yes, the hangs are on the 3.2-R client. An upgrade is currently in the works... Actually it's slated for installation next week. Hopefully that will help kick NFS into shape for me. > :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. Something strange, certainly... I don't recall changing the mount status of any of those, or mounting/unmounting anything at all for that matter. Didn't see anything weird in messages. Could still have been recent pilot error, I suppose. However, exports on the server haven't changed in eight months and that 'bigfs' was mounted at boot from fstab on the client, many months ago. Nothing OOTO in exports or fstab.. The mounts look pretty homogenous. That's what made me think something was strange; several other similarly-mapped mounts between the same two machines never missed a beat. HOWEVER... (Update, here)... When I finally got in to the office today, I did a `umount -a -t nfs &` on the client (the & for the purpose of regaining my shell while umount hung trying to unmount bigfs :-). Then killed off mountd, nfsd, portmap, and even inetd in that order, and restarted them in the reverse of that order. The hung processes on the client magically became unstuck and terminated, and I was able to unmount that muddled bigfs and start over. Everything seems to be in working order once again. Perhaps the 3.2 client isn't solely to blame, here, after all. I'll try this all again when both machines are running -STABLE. > :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. Performance = transfer rates and latency? Or just generalized stability? I haven't had the time to watch -CURRENT all that closely, but I'll be happy when some of the new functionality becomes -STABLE. Thanks for the reply, - Ryan -- Ryan Thompson <[EMAIL PROTECTED]> Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Annoying nfsrcv hangs
: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
Annoying nfsrcv hangs
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 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 Foldger's crystals. Think he'll taste the difference?" It appears to be the cause of the hangs I mentioned. One such hang was one that I just created by issuing umount -f bigfs. The client nfs mounts are mounted intr, yet I still can't send a TERM or KILL that these processes will catch. # grep bigfs /etc/fstab 10.0.0.2:/bigfs /f/bigfsnfs rw,bg,intr 2 2 The client is a 3.2-RELEASE system. Server is 3.4-STABLE as of about 12 days ago. It looks like reboots are in order... But, these are production machines! This is certainly annoying...! I thought the intr option was supposed to help with hung nfs procs. Is there anything else I can try in my current situation? Any better ways to prevent this sort of thing (besides running SunOS?) Or is it PR time? # uptime 1:46AM up 118 days 1:14, 12 users, load averages: 2.36, 2.34, 2.21 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, - Frustrated :-) -- Ryan Thompson <[EMAIL PROTECTED]> Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
