On Tue, Apr 29, 2008 at 10:45:03AM -0400, Wendy Cheng wrote: > Janne Karhunen wrote: >> On Sun, Apr 20, 2008 at 8:02 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: >> >> >>> > > Right, that's what would make the most sense to me. Janne, is there any >>> > > reason that wouldn't solve your problem? >>> > >>> > I didn't get the idea. So the idea is to use multiple sockets, >>> > one bound to LOOPBACK and one to external interface? >>> >>> I suppose so. One socket would be for communication for the local >>> kernel nfsd, one for communication with statd peers. >>> >> >> Finally got around to it again. Attached patch takes a >> shot at the two socket approach. Patch is a draft to >> see what you guys would really think about this >> approach. >> >> > Do we really have to add so many lines of the code just to fix "statd > -n" ? Maybe we should go back to the basics by understanding the > requirement of this command ? So why do we need it (i.e. what kind of > bad things we'll see if we don't fix this) ? Some short description > would help. I recall two reasons for -n given in this thread; I think one was just security (maybe you don't want statd listening on some ports, for whatever reason. The other was a code comment quoted here: http://marc.info/?l=linux-nfs&m=120854237320424&w=2 "This is required to support clients that ignore the mon_name in the statd protocol but use the source address from the request packet." Which I don't completely understand. I guess it was meant as a way to ensure that *outgoing* packets are sent from the correct (floating) ip address? --b. -- 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
