10:35 a.m.
Hi,
I’ll have to take a closer look, but I should warn you that using NFS over UDP is strongly
discouraged. Today’s fast networks are fast enough that there can be problems with UDP
packet re-assembly since the 16 bit packet ID can wrap within the lifetime of a packet
resulting in fragments from older packets being reassembled with fragments of newer
packets. Most of the time this cause checksum errors (which then affect performance) but
it IS possible to produce data corruption if the 16 bit checksum happens to still be OK
(possibly occurring for 1 in 65k packets).
Frank
From: Sagar Singh [mailto:sagar.it.iiests@gmail.com]
Sent: Monday, April 24, 2023 11:19 PM
To: devel(a)lists.nfs-ganesha.org
Subject: [NFS-Ganesha-Devel] UDP mount in nfs-ganesha
Hi, We are trying to work on a UDP mount for ganesha, and need some feedback.
For NLM lock recovery we use the node local ip address of ganesha server-node. It works
perfectly fine with the TCP mount.
But with the UDP mount we have seen that local rq_xprt->xp_local.nb.buf points to valid
local-ip, however rq_xprt->xp_local.ss have ip address ADDR_ANY.
(gdb) p *((struct sockaddr_in*)&reqdata->svc->rq_xprt->
<http://xp_local.ss/> xp_local.ss)
$2 = {sin_family = 2, sin_port = 264, sin_addr = {s_addr = 0},
sin_zero = "\000\000\000\000\000\000\000"}
(gdb) p *((struct sockaddr_in*)reqdata->svc->rq_xprt->xp_local.nb.buf)
$3 = {sin_family = 3, sin_port = 0, sin_addr = {s_addr = 2237796106},
sin_zero = "\n\017b\205\000\000\000"}
Which causes problems in lock recovery and other functionalities. We have made some
changes in the initialization code of local ip:
https://github.com/nfs-ganesha/ntirpc/pull/273/files
Which seems to resolve the issue of the local address being ADDR_ANY and lock recovery
works fine.
We are not sure that :-
1. Will this fix work with all kinds of clients?
2. Will this break any existing functionalities?
Any feedback will be greatly appreciated.
Thanks,
Sagar Singh