Hi folks,
There is no documentation of this behavior but when "noresvport" is
specified, the client will not try to re-use the port upon connection
re-establishement. Is this an oversight or a desired behavior (ie.,
client doesn't need to be conservative and re-use ports)?
Thank you.
On Thu, Aug 2, 2018 at 11:14 AM, Olga Kornievskaia <[email protected]> wrote:
> Hi folks,
>
> There is no documentation of this behavior but when "noresvport" is
> specified, the client will not try to re-use the port upon connection
> re-establishement. Is this an oversight or a desired behavior (ie.,
> client doesn't need to be conservative and re-use ports)?
>
> Thank you.
I'm going to speculate on the reason myself and would like to hear
some folks thoughts.
When we specify "noresvport" we use port=0 value that tells the kernel
- use any port. When connection is re-established port=0 so NFS has no
control over which port the kernel will choose.
When client re-establishes the connection with a different port, that
has an effect on the server's replay cache. Any thoughts on that?
Should the client remember which non-privileged port it used and then
the next time request a specific port? Is that possible?
> On Aug 2, 2018, at 12:42 PM, Olga Kornievskaia <[email protected]> wrote:
>
> On Thu, Aug 2, 2018 at 11:14 AM, Olga Kornievskaia <[email protected]> wrote:
>> Hi folks,
>>
>> There is no documentation of this behavior but when "noresvport" is
>> specified, the client will not try to re-use the port upon connection
>> re-establishement. Is this an oversight or a desired behavior (ie.,
>> client doesn't need to be conservative and re-use ports)?
>>
>> Thank you.
>
> I'm going to speculate on the reason myself and would like to hear
> some folks thoughts.
>
> When we specify "noresvport" we use port=0 value that tells the kernel
> - use any port. When connection is re-established port=0 so NFS has no
> control over which port the kernel will choose.
>
> When client re-establishes the connection with a different port, that
> has an effect on the server's replay cache. Any thoughts on that?
>
> Should the client remember which non-privileged port it used and then
> the next time request a specific port?
The basic constraint is that:
If the client actively disconnects, or if the client is using an NFSv4
session, then for a fresh connection the client is free to use any
available source port in the range selected by the "resvport" mount
option.
If there is no NFSv4 session and the server or the network transport
actively disconnects (say, due to a keep-alive timeout), the client
should attempt to use the same source port as the previous connection
in order to preserve DRC content on the server.
> Is that possible?
--
Chuck Lever
On Mon, Aug 6, 2018 at 10:46 AM, Chuck Lever <[email protected]> wrote:
>
>
>> On Aug 2, 2018, at 12:42 PM, Olga Kornievskaia <[email protected]> wrote:
>>
>> On Thu, Aug 2, 2018 at 11:14 AM, Olga Kornievskaia <[email protected]> wrote:
>>> Hi folks,
>>>
>>> There is no documentation of this behavior but when "noresvport" is
>>> specified, the client will not try to re-use the port upon connection
>>> re-establishement. Is this an oversight or a desired behavior (ie.,
>>> client doesn't need to be conservative and re-use ports)?
>>>
>>> Thank you.
>>
>> I'm going to speculate on the reason myself and would like to hear
>> some folks thoughts.
>>
>> When we specify "noresvport" we use port=0 value that tells the kernel
>> - use any port. When connection is re-established port=0 so NFS has no
>> control over which port the kernel will choose.
>>
>> When client re-establishes the connection with a different port, that
>> has an effect on the server's replay cache. Any thoughts on that?
>>
>> Should the client remember which non-privileged port it used and then
>> the next time request a specific port?
>
> The basic constraint is that:
>
> If the client actively disconnects, or if the client is using an NFSv4
> session, then for a fresh connection the client is free to use any
> available source port in the range selected by the "resvport" mount
> option.
>
> If there is no NFSv4 session and the server or the network transport
> actively disconnects (say, due to a keep-alive timeout), the client
> should attempt to use the same source port as the previous connection
> in order to preserve DRC content on the server.
Hi Chuck,
Thanks for the reply. I'm considering your 2nd case where the server
reset the connection and client is re-establishing it and this is a v3
mount (this DRC is important). When "noresvport" is specified, then
the kernel makes no attempts at re-use the same non-reserved port.
However, I'm not sure it is possible to re-use a non-reserved port.
Given this behavior, shouldn't we be discouraging folks to mount with
v3 and "noresvport" option?
>
>
>> Is that possible?
>
>
> --
> Chuck Lever
>
>
>
> On Aug 6, 2018, at 12:06 PM, Olga Kornievskaia <[email protected]> wrote:
>=20
> On Mon, Aug 6, 2018 at 10:46 AM, Chuck Lever <[email protected]> =
wrote:
>>=20
>>=20
>>> On Aug 2, 2018, at 12:42 PM, Olga Kornievskaia <[email protected]> =
wrote:
>>>=20
>>> On Thu, Aug 2, 2018 at 11:14 AM, Olga Kornievskaia <[email protected]> =
wrote:
>>>> Hi folks,
>>>>=20
>>>> There is no documentation of this behavior but when "noresvport" is
>>>> specified, the client will not try to re-use the port upon =
connection
>>>> re-establishement. Is this an oversight or a desired behavior (ie.,
>>>> client doesn't need to be conservative and re-use ports)?
>>>>=20
>>>> Thank you.
>>>=20
>>> I'm going to speculate on the reason myself and would like to hear
>>> some folks thoughts.
>>>=20
>>> When we specify "noresvport" we use port=3D0 value that tells the =
kernel
>>> - use any port. When connection is re-established port=3D0 so NFS =
has no
>>> control over which port the kernel will choose.
>>>=20
>>> When client re-establishes the connection with a different port, =
that
>>> has an effect on the server's replay cache. Any thoughts on that?
>>>=20
>>> Should the client remember which non-privileged port it used and =
then
>>> the next time request a specific port?
>>=20
>> The basic constraint is that:
>>=20
>> If the client actively disconnects, or if the client is using an =
NFSv4
>> session, then for a fresh connection the client is free to use any
>> available source port in the range selected by the "resvport" mount
>> option.
>>=20
>> If there is no NFSv4 session and the server or the network transport
>> actively disconnects (say, due to a keep-alive timeout), the client
>> should attempt to use the same source port as the previous connection
>> in order to preserve DRC content on the server.
>=20
> Hi Chuck,
>=20
> Thanks for the reply. I'm considering your 2nd case where the server
> reset the connection and client is re-establishing it and this is a v3
> mount (this DRC is important). When "noresvport" is specified, then
> the kernel makes no attempts at re-use the same non-reserved port.
> However, I'm not sure it is possible to re-use a non-reserved port.
Why do you believe that?
> Given this behavior, shouldn't we be discouraging folks to mount with
> v3 and "noresvport" option?
--
Chuck Lever
> On Aug 6, 2018, at 1:49 PM, Chuck Lever <[email protected]> =
wrote:
>=20
>=20
>=20
>> On Aug 6, 2018, at 12:06 PM, Olga Kornievskaia <[email protected]> =
wrote:
>>=20
>> On Mon, Aug 6, 2018 at 10:46 AM, Chuck Lever <[email protected]> =
wrote:
>>>=20
>>>=20
>>>> On Aug 2, 2018, at 12:42 PM, Olga Kornievskaia <[email protected]> =
wrote:
>>>>=20
>>>> On Thu, Aug 2, 2018 at 11:14 AM, Olga Kornievskaia <[email protected]> =
wrote:
>>>>> Hi folks,
>>>>>=20
>>>>> There is no documentation of this behavior but when "noresvport" =
is
>>>>> specified, the client will not try to re-use the port upon =
connection
>>>>> re-establishement. Is this an oversight or a desired behavior =
(ie.,
>>>>> client doesn't need to be conservative and re-use ports)?
>>>>>=20
>>>>> Thank you.
>>>>=20
>>>> I'm going to speculate on the reason myself and would like to hear
>>>> some folks thoughts.
>>>>=20
>>>> When we specify "noresvport" we use port=3D0 value that tells the =
kernel
>>>> - use any port. When connection is re-established port=3D0 so NFS =
has no
>>>> control over which port the kernel will choose.
>>>>=20
>>>> When client re-establishes the connection with a different port, =
that
>>>> has an effect on the server's replay cache. Any thoughts on that?
>>>>=20
>>>> Should the client remember which non-privileged port it used and =
then
>>>> the next time request a specific port?
>>>=20
>>> The basic constraint is that:
>>>=20
>>> If the client actively disconnects, or if the client is using an =
NFSv4
>>> session, then for a fresh connection the client is free to use any
>>> available source port in the range selected by the "resvport" mount
>>> option.
>>>=20
>>> If there is no NFSv4 session and the server or the network transport
>>> actively disconnects (say, due to a keep-alive timeout), the client
>>> should attempt to use the same source port as the previous =
connection
>>> in order to preserve DRC content on the server.
>>=20
>> Hi Chuck,
>>=20
>> Thanks for the reply. I'm considering your 2nd case where the server
>> reset the connection and client is re-establishing it and this is a =
v3
>> mount (this DRC is important). When "noresvport" is specified, then
>> the kernel makes no attempts at re-use the same non-reserved port.
>> However, I'm not sure it is possible to re-use a non-reserved port.
>=20
> Why do you believe that?
That was terse. What I mean is, I don't know whether it is possible or
not to re-use an ephemeral port. I don't know of a reason why it would
not be possible to re-use one. Do you?
>> Given this behavior, shouldn't we be discouraging folks to mount with
>> v3 and "noresvport" option?
--
Chuck Lever
On Mon, Aug 6, 2018 at 2:01 PM, Chuck Lever <[email protected]> wrote:
>
>
>> On Aug 6, 2018, at 1:49 PM, Chuck Lever <[email protected]> wrote:
>>
>>
>>
>>> On Aug 6, 2018, at 12:06 PM, Olga Kornievskaia <[email protected]> wrote:
>>>
>>> On Mon, Aug 6, 2018 at 10:46 AM, Chuck Lever <[email protected]> wrote:
>>>>
>>>>
>>>>> On Aug 2, 2018, at 12:42 PM, Olga Kornievskaia <[email protected]> wrote:
>>>>>
>>>>> On Thu, Aug 2, 2018 at 11:14 AM, Olga Kornievskaia <[email protected]> wrote:
>>>>>> Hi folks,
>>>>>>
>>>>>> There is no documentation of this behavior but when "noresvport" is
>>>>>> specified, the client will not try to re-use the port upon connection
>>>>>> re-establishement. Is this an oversight or a desired behavior (ie.,
>>>>>> client doesn't need to be conservative and re-use ports)?
>>>>>>
>>>>>> Thank you.
>>>>>
>>>>> I'm going to speculate on the reason myself and would like to hear
>>>>> some folks thoughts.
>>>>>
>>>>> When we specify "noresvport" we use port=0 value that tells the kernel
>>>>> - use any port. When connection is re-established port=0 so NFS has no
>>>>> control over which port the kernel will choose.
>>>>>
>>>>> When client re-establishes the connection with a different port, that
>>>>> has an effect on the server's replay cache. Any thoughts on that?
>>>>>
>>>>> Should the client remember which non-privileged port it used and then
>>>>> the next time request a specific port?
>>>>
>>>> The basic constraint is that:
>>>>
>>>> If the client actively disconnects, or if the client is using an NFSv4
>>>> session, then for a fresh connection the client is free to use any
>>>> available source port in the range selected by the "resvport" mount
>>>> option.
>>>>
>>>> If there is no NFSv4 session and the server or the network transport
>>>> actively disconnects (say, due to a keep-alive timeout), the client
>>>> should attempt to use the same source port as the previous connection
>>>> in order to preserve DRC content on the server.
>>>
>>> Hi Chuck,
>>>
>>> Thanks for the reply. I'm considering your 2nd case where the server
>>> reset the connection and client is re-establishing it and this is a v3
>>> mount (this DRC is important). When "noresvport" is specified, then
>>> the kernel makes no attempts at re-use the same non-reserved port.
>>> However, I'm not sure it is possible to re-use a non-reserved port.
>>
>> Why do you believe that?
>
> That was terse. What I mean is, I don't know whether it is possible or
> not to re-use an ephemeral port. I don't know of a reason why it would
> not be possible to re-use one. Do you?
>
I'm thinking the way the API works is that we set port=0 when we setup
the socket which tells the kernel to use any non-privilege port. I'm
hazy on the details of how the reconnection is happening. So I'm
thinking kernel tells us the connection got closed and we call into
kernel to re-connect. I think the port at the reconnect time is again
just 0 which tells the kernel "use any port". To make it possible to
re-use the port, I think we(NFS) need to save the port from the
"original" connection and then connecting again instead of the 0
specify the saved port? That's my hand wavy explanation of port
re-use.
>>> Given this behavior, shouldn't we be discouraging folks to mount with
>>> v3 and "noresvport" option?
>
> --
> Chuck Lever
>
>
>