Hi Frank, This is with latest version of Ganesha. The referral support is already in VFS: https://review.gerrithub.io/c/353684
tcpdump is attached. From the tcpdump, we can see that the stat sent a LOOKUP for the remote export and received a moved error. It also sent back the fs_locations. But the client (CentOS 7.3) never followed that with a LOOKUP to the remote server. You can see that packet #41 has the correct FS locations. But client does not do another lookup to get the correct attributes. $ stat /mnt/nfs_d1 File: ‘/mnt/nfs_d1’ Size: 0 Blocks: 0 IO Block: 1048576 directory Device: 28h/40d Inode: 1 Links: 2 Access: (0555/dr-xr-xr-x) Uid: (4294967294/ UNKNOWN) Gid: (4294967294/ UNKNOWN) Context: system_u:object_r:nfs_t:s0 Access: 1969-12-31 16:00:00.000000000 -0800 Modify: 1969-12-31 16:00:00.000000000 -0800 Change: 1969-12-31 16:00:00.000000000 -0800 Birth: - On Mon, Oct 30, 2017 at 12:13 PM, Frank Filz <ffilz...@mindspring.com> wrote: > What version of Ganesha? I assume by “native” FSAL, you mean FSAL_VFS? Did > you add the fs locations XATTR support? FSAL_GPFS currently has the only > in-tree referral support and I’m not sure it necessarily works, but I’m > unable to test it. > > > > If you have code for FSAL_VFS to add the fs locations attribute, go ahead > and post it and I could poke at it. > > > > Also, tcpdump traces might help understand what is going wrong. > > > > Frank > > > > *From:* Pradeep [mailto:pradeep.tho...@gmail.com] > *Sent:* Monday, October 30, 2017 11:45 AM > *To:* nfs-ganesha-devel <nfs-ganesha-devel@lists.sourceforge.net> > *Cc:* ssaurabh.w...@gmail.com > *Subject:* [Nfs-ganesha-devel] NFSv4 referrals not working with ganesha. > > > > Hi all, > > > > We are testing NFSv4 referral for Linux CentOS 7 with nfs-ganesha and are > running > > into some serious issues. > > > > Although, we were able to set up NFSv4 referral using the native Ganesha > FSAL, > > we could not get it fully functional for all Linux client system calls. > > Basically, the NFSv4 spec suggests to return a NFS4ERR_MOVED on a > > LOOKUP done for a remote export. However, this breaks the `stat` system > call on > > Linux CentOS 7 (stat’ results in a LOOKUP,GETFH,GETATTR compound). An easy > way to > > reproduce the broken behavior is: > > 1) mount the root of the pseudo file system and > > 2) issue a `stat` command on the remote export. > > The stat returned are corrupt. > > > > After digging into the CentOS 7 client code, we realized that the stat > operation > > is never expected to follow the referral. However, switching to returning > NFS4_OK > > for stat, then breaks `cd` or a `ls -l` command, because now we don't know > when > > to follow the referral. > > > > Does anyone have a successful experience in setting up the NFSv4 referrals > that > > they could share? Or, if some suggestions on what we might be doing wrong? > > > > Thanks > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link> > <#m_-471076988347431713_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >
nfs_remote_export1.pcap
Description: Binary data
------------------------------------------------------------------------------ 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
