Yes, the fix looks straight forward. Let me work on it, will submit the review
soon.
Thanks,
Sriram
From: Frank Filz <ffilz...@mindspring.com>
Date: Wednesday, January 17, 2018 at 8:24 PM
To: Sriram Patil <srir...@vmware.com>,
"nfs-ganesha-devel@lists.sourceforge.net"
<nfs-ganesha-devel@lists.sourceforge.net>
Cc: Kamal Charan <kcha...@vmware.com>, Sakthi Kumar <sakt...@vmware.com>
Subject: RE: [Nfs-ganesha-devel] [FSAL_VFS] NFSv4 referrals not working
Ok, I see the issue. In the past, I believe referrals have always been used
with exports where Path and Pseudo were the same (note that prior to the
addition of the mount_path_pseudo option, doing otherwise was confusing to NFS
v3 clients since they would have a different mount path to the export).
I think the solution is simple, before filling in fs_root, we need to check if
the current export’s Path is different from Pseudo, and if so, replace the
portion of fs_root that is Path in the string with the Pseudo path.
Frank
From: Sriram Patil [mailto:srir...@vmware.com]
Sent: Wednesday, January 17, 2018 1:56 AM
To: nfs-ganesha-devel@lists.sourceforge.net
Cc: Kamal Charan <kcha...@vmware.com>; Sakthi Kumar <sakt...@vmware.com>
Subject: [Nfs-ganesha-devel] [FSAL_VFS] NFSv4 referrals not working
Hi,
I was experimenting with NFSv4 referrals recently and I have not been able to
get it working. I tried this on stable version 2.5, so it has referrals changes
in VFS code. Here’s what I did,
Server A: Path=/A/real/path; Pseudo=/A/pseudo/path
Server B: Path=/B/real/path; Pseudo=/B/pseudo/path
/A/real/path has a directory named “refer_B”, I made the following changes to
make it a referral directory
chmod –x refer_B; chmod +t refer_B
setfattr –n user.fs_location –v “<server B ip>:/B/pseudo/path” refer_b
This means, whenever a user tries to step inside “refer_B” directory it should
be redirected to <server B ip>:/B/pseudo/path.
Now, when client requests fs_locations from server A, it sends the fs_locations
by reding xattr “user.fs_location”. But, the fs_root is taken from
obj_hdl->u.directory.path. This is populated in lookup_with_fd function in
FSAL_VFS. It opens the file from handle and then populates the directory path
by reading the symlink from “/proc/self/fd”.
In this example, obj_hdl->u.directory.path=”/A/real/path/refer_B”. This is sent
as fs_root to client. Server will always see the real path because pseudo path
does not exist.
On the NFS client, it tries to validate the fs_root (named as fs_path in linux
nfs client). [function: nfs4_validate_fspath]. It creates the full path for
refer_B from dentry cache, which comes out as “/A/pseudo/path/refer_B”, because
client only knows the pseudo path. It checks if the fs_root
(/A/real/path/refer_B) is prefix of “/A/pseudo/path/refer_B”. This check fails
and we get ENOENT error.
The client logs can be found below,
Jan 17 01:26:36 UbuntuWorker kernel: decode_attr_fs_locations: fsroot:
Jan 17 01:26:36 UbuntuWorker kernel: pathname4: / A / real / path / refer_B
Jan 17 01:26:36 UbuntuWorker kernel: decode_attr_fs_locations: servers:
Jan 17 01:26:36 UbuntuWorker kernel: <server B ip>
Jan 17 01:26:36 UbuntuWorker kernel: pathname4:
Jan 17 01:26:36 UbuntuWorker kernel: / B / pseudo / path
…….
Jan 17 01:26:36 UbuntuWorker kernel: _nfs4_proc_fs_locations: returned status = 0
Jan 17 01:26:36 UbuntuWorker kernel: nfs_follow_referral: referral at /refer_B
Jan 17 01:26:36 UbuntuWorker kernel: nfs4_validate_fspath: path
/A/pseudo/path/refer_B does not begin with fsroot /A/real/path/refer_B
Jan 17 01:26:36 UbuntuWorker kernel: nfs_follow_referral: done
Jan 17 01:26:36 UbuntuWorker kernel: nfs_do_refmount: done
Jan 17 01:26:36 UbuntuWorker kernel: RPC: shutting down nfs client for
<server B ip>
Jan 17 01:26:36 UbuntuWorker kernel: RPC:
rpc_release_client(ffff880429c73a00)
Jan 17 01:26:36 UbuntuWorker kernel: RPC: destroying nfs client for
<server B ip>
Jan 17 01:26:36 UbuntuWorker kernel: <-- nfs_d_automount(): error -2
Jan 17 01:26:36 UbuntuWorker kernel: NFS: dentry_delete(/refer_B, 3a00cc)
I see that people have said that referrals work fine with Ganesha FSAL_VFS. Am
I missing something here?
Thanks,
Sriram
[mage removed by
sender.]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avast.com_sig-2Demail-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcampaign-3Dsig-2Demail-26utm-5Fcontent-3Demailclient-26utm-5Fterm-3Dicon&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=3mYu-6ji6Qx1wg_jv5mtp8E_l5KQMHnNPIWlSioZ7IE&m=FE8NnJB-kH-pJs2Ps5Kb1WDv6BClxtq4kndWHudeWi4&s=671xriZC2IR0-vFHAcSGSfcnclVK7B_b0Boh7rYPdO4&e=>
Virus-free.
www.avast.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.avast.com_sig-2Demail-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcampaign-3Dsig-2Demail-26utm-5Fcontent-3Demailclient-26utm-5Fterm-3Dlink&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=3mYu-6ji6Qx1wg_jv5mtp8E_l5KQMHnNPIWlSioZ7IE&m=FE8NnJB-kH-pJs2Ps5Kb1WDv6BClxtq4kndWHudeWi4&s=o6eGK_ZYX8HPal1N7LLU-PNKvEfUOxR4564_sZIAxkQ&e=>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
