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. > 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
