On Sat, Feb 10, 2024 at 06:07:50PM +0530, gaurav gangalwar wrote: > Thanks for the response. > I was checking the nfs_follow_referral code, I think we already have this > patch to fix the same issue > I copied http link in previous reply, it got bounced back, so I copied the > commit message in plain text. > > > commit 530ea4219231e62341f79a5517d7b4f12ec3b74f > > Author: Chuck Lever <chuck.lever@xxxxxxxxxx> > > Date: Mon Dec 4 14:13:38 2017 -0500 > > > > nfs: Referrals should use the same proto setting as their parent > > > > Helen Chao <helen.chao@xxxxxxxxxx> noticed that when a user > > traverses a referral on an NFS/RDMA mount, the resulting submount > > always uses TCP. > > > > This behavior does not match the vers= setting when traversing > > a referral (vers=4.1 is preserved). It also does not match the > > behavior of crossing from the pseudofs into a real filesystem > > (proto=rdma is preserved in that case). > > > > The Linux NFS client does not currently support the > > fs_locations_info attribute. The situation is similar for all > > NFSv4 servers I know of. Therefore until the community has broad > > support for fs_locations_info, when following a referral: > > > > - First try to connect with RPC-over-RDMA. This will fail quickly > > if the client has no RDMA-capable interfaces. > > > > - If connecting with RPC-over-RDMA fails, or the RPC-over-RDMA > > transport is not available, use TCP. > > > As per code, with CONFIG_SUNRPC_XPRT_RDMA we should always try with RDMA > first and fallback to TCP if it fails, Is it not valid anymore? This is ancient history for me, so pardon any memory lapses. This logic should cause the NFS client to try NFS/RDMA first when following an NFSv4 referral. So if that isn't working for you, you will need to debug the problem with your hardware and fabric. -- Chuck Lever
