Janne Karhunen wrote:
> On Sun, Apr 20, 2008 at 8:02 PM, J. Bruce Fields <[email protected]> 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.
-- Wendy
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 <[email protected]> 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.
On Tue, Apr 29, 2008 at 12:16 PM, J. Bruce Fields <[email protected]> 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