Hi, So effectively, it makes me sleep better. With it: - I can rely on clients identifying the server correctly, - I'm not exposing out anything that is not needed, - Can tell by the address what this traffic is, - Can be sure that packets are sent out via right interface It might be even better if it would exit if -n is used when no such interface is actually available. As I did it, it still gambles here just as before. -- // Janne On Thu, May 1, 2008 at 8:57 AM, Janne Karhunen <janne.karhunen@xxxxxxxxx> wrote: > On Tue, Apr 29, 2008 at 12:16 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > > Do we really have to add so many lines of the code just to fix "statd > > > -n" > > Which is why I offered the small patch initially; it was > mentioned that intrusiveness does not matter if it > can be kept in userspace. > > > > > > ? 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: > > That being one.. > > > > > 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." > > This another, and the third the fact that this way mon_name > stays the same on server failover to node that has different > name. It identifies the server instance.. > > > > > 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? > > Right. > > > -- > // Janne > -- 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