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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
------------------------------------------------------------------------------
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

Reply via email to