Date: Sun, 22 Nov 1998 16:32:25 -0800 (PST) From: dan@math.berkeley.edu (Dan Strick) To: obrien@NUXI.com Cc: dan@math.berkeley.edu, hackers@FreeBSD.ORG Subject: Re: AMD/NFS problems with 3.0 Message-ID: <199811230032.QAA03103@math.berkeley.edu>
next in thread | raw e-mail | index | archive | help
(Please ignore my previous posting. I somehow neglected to rewrite the temporary mail message file after editing it into this:) > > At first I though this might be related to these messages that went > > to the log the first time I started amd: > > > > noconn option exists, and was turned OFF! (May cause NFS hangs > > on some systems...) > > These are always printed out. I guess I should comment them out, or > determine if we really can use the optimization. The comments in the > code by the Columbia people are often out of date with respect to > FreeBSD-CURRENT. I have often wondered what this was really about. Can someone explain? At first I thought the issue was tcp versus udp, but this turns out to be wrong. The issue seems to be if the BSD connect() system call is used to associate the local BSD datagram (i.e. UDP) "socket" with the remote nfs server datagram "socket". The alternative would be to skip the connect() and specify the destination address every time a packet is sent and examine the source address every time a packet is received. I don't really understand the issue here. UDP is essentially a connectionless protocol. I don't understand the function of the BSD connect() system call other than as a programming convenience. I don't see why it should cause a noticeable performance improvement. It does have the effect of causing NFS responses to be rejected if they don't come from the same IP address/port# to which the NFS request was sent and this causes NFS mounts to hang if the NFS server has multiple internet interfaces and chooses to send its responses back through a different interface. (I have not yet noticed an NFS server responding through a different port#.) My workaround has always been to specify the "noconn" option for amd nfs mounts. Beginning sometime between 2.2.5-RELEASE and 3.0-RELEASE, the amd automounter and perhaps the OS were changed so that the thing to do was to specify the "conn" option in the amd maps. Then you don't get the above warning message and your remote mounts don't hang. This is contrary to my weak understanding of the issue. Can someone explain why we must now "conn" where previously we had to "noconn"? The 3.0-RELEASE/RELNOTES.TXT file says: The Amd automounter has been updated from the 1993 4.4BSD version to the latest current version of am-utils. Map options have changed somewhat, and a new configuration file, /etc/amd.conf, is supported. See ``man 5 amd.conf''. It might be helpful if the "conn" change was specifically mentioned and this paragraph was restored to the "USERLAND CHANGES" section of the release notes. It certainly confused the heck out of me for a while. I had to read the amd sources to figure out how to fix my amd configuration. Dan Strick dan@math.berkeley.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811230032.QAA03103>