At 12:42 PM 5/7/2009, Chuck Lever wrote: >On May 7, 2009, at 12:08 PM, Aaron Wiebe wrote: >> On Thu, May 7, 2009 at 11:35 AM, Tom Talpey <tmtalpey@xxxxxxxxx> >> wrote: >>> >>> There is one small caveat to using mountproto=tcp through firewalls: >>> while the mount will succeed, there are some side protocol exchanges >>> which may not. >>> >>> In particular, if you do NLM file locking, there is a server >>> callback (NLM >>> "granted") which the server may choose to issue via UDP. If this >>> callback >>> is not seen by the client due to firewall blocking, there may be a >>> 30-second >>> pause before a client retry unblocks the caller. >>> >>> Also, the NSM (status monitor) exchanges are often performed via UDP. >>> Again, if you are using NLM and the server reboots, the client may >>> not >>> become aware of this promptly, and lock reclaim will be affected. >> >> Sorry for the slight threadjack, but a question along those lines... >> >> My understanding is that currently portmap will not bind any UDP NLM >> listeners unless there are UDP mounts on the machine. > >It's not portmap... lockd decides which listeners to start. Also, there is an important distinction between NLM and NLM *callbacks*. The NLM client follows the NFS protocol selection in many client kernels, i.e. if you mount with proto=tcp, you get both NFS and NLM over TCP. The issue is NLM callbacks, which are used only in specific cases where clients take blocking locks, which actually need to block due to being already held by another client. The server replies over NLM (e.g. TCP) with an indication that a callback will arive later. But when the other lock is released, the callback comes on a second connection, initiated from the server back to the client and not on the original NLM channel. To make matters worse, some servers only ever perform the callback on UDP in order to simplify and reduce the overhead required. If this callback doesn't arrive at the client, or arrives in such a way that it's not recognized (e.g traverses a NAT and therefore changes source IP), then the client only wakes up on a timer. The long pauses can be a real problem, and one which only arises occasionally - i.e. very hard to trace down. Just something to be aware of... it's a day-one defect in the NLM protocol, actually. Tom. > >> I know there >> are servers out there that will always speak NLM over UDP >> (netapp/ontap being the prominent one), and as a result there can be >> problems without firewalls. If servers are out there that will speak >> NLM over UDP regardless of the mount itself, shouldn't we be binding >> NLM/UDP regardless of the mount transport? >> >> (Or did I miss this change being reverted a while back?) > >This change was reverted upstream; see commit 8c3916f4. > >-- >Chuck Lever >chuck[dot]lever[at]oracle[dot]com > ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ NFS maillist - NFS@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/nfs _______________________________________________ Please note that nfs@xxxxxxxxxxxxxxxxxxxxx is being discontinued. Please subscribe to linux-nfs@xxxxxxxxxxxxxxx instead. http://vger.kernel.org/vger-lists.html#linux-nfs -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
