> On Aug 2, 2018, at 12:42 PM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Thu, Aug 2, 2018 at 11:14 AM, Olga Kornievskaia <aglo@xxxxxxxxx> 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 -- 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
