7:39 a.m.
Okay, so I think this has to be a client bug. Looking through the
packet dump, every GETATTRS on e2/ or e3/ returns NFS4ERR_MOVED. Every
time this happens, the client immediately sends a GETATTRS asking for
fs_locations, and the response has the correct data. That is, the
response for e2/ has localhost:e1/ and e3/ has 10.193.9.87:TestShare-1.
So Ganesha appears to be doing the correct thing.
Two suggestions at this point, I guess. 1. Try with a newer client, and
see if it's an already-fixed bug; and 2. bring this up on the Linux NFS
list. I can chime in there if any of the devs have questions. I'm
guessing that multiple referrals at the same level isn't a commonly
tested scenario upstream?
Daniel
On 3/19/19 11:19 PM, Sriram Patil wrote:
Please find the packet trace attached.
- Sriram
On 3/20/19, 12:26 AM, "Daniel Gryniewicz" <dang(a)redhat.com> wrote:
On 3/19/19 9:56 AM, Sriram Patil wrote:
> Hi,
>
> I am observing strange behavior with referrals. NFS client always is always
taking the fs locations of the first referral and not honoring rest of the referrals.
>
> For example, I have 3 exports e1, e2 and e3. e2 is a referral pointing to e1
and e3 is a referral pointing to a remote server.
>
> $> getfattr -n user.fs_location /exports/e2
> getfattr: Removing leading '/' from absolute path names
> # file: exports/e2
> user.fs_location="localhost:/e1"
>
> $> getfattr -n user.fs_location /exports/e3
> getfattr: Removing leading '/' from absolute path names
> # file: exports/e3
> user.fs_location="10.193.9.87:/TestShare-1"
>
>
> Here’s what happens when the localhost:/ is mounted
>
> $> sudo mount -t nfs4 -o minorversion=1,sec=sys localhost:/ /mnt/m1
>
> $> ls -l /mnt/m1
> total 4
> drwxr-xr-x 4 root root 4096 Mar 16 19:51 e1
> dr-xr-xr-x 2 4294967294 4294967294 0 Dec 31 1969 e2 # referral
> dr-xr-xr-x 2 4294967294 4294967294 0 Dec 31 1969 e3 # referral
>
> $> ls -l /mnt/m1/e2 # follows referral and mounts localhost:/e1
> total 8
> drwxr-xr-x 2 root root 4096 Mar 16 19:59 tmp
> drwxr-xr-x 3 root root 4096 Mar 16 19:51 tree
>
> $> ls -li /mnt/m1
> total 12
> 1 drwxr-xr-x 4 root root 4096 Mar 16 19:51 e1
> 5505026 drwxr-xr-x 4 root root 4096 Mar 16 19:51 e2 # after referral mount
both e2 and e3 show the same inode number
> 5505026 drwxr-xr-x 4 root root 4096 Mar 16 19:51 e3
>
> $> ls -l /mnt/m1/e3 # trying to mount e3 but shows the
same contents as e2
> total 8
> drwxr-xr-x 2 root root 4096 Mar 16 19:59 tmp
> drwxr-xr-x 3 root root 4096 Mar 16 19:51 tree
>
> $> mount -t nfs4
> localhost:/ on /mnt/m1 type nfs4
(rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1)
> localhost:/e1 on /mnt/m1/e3 type nfs4
(rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,local_lock=none,addr=127.0.0.1)
>
>
> As observed from the mount command output above, "localhost:/e1" is
mounted at /mnt/m1/e3. However, e3 was pointing to "10.193.9.87:/TestShare-1".
>
> Whichever referral is mounted first, all the other referral point to the same
one no matter what. Confusing thing is ganesha log, NFS packets and client side rpcdebug
log, all show correct values of fs locations. But the client does not trigger a sub-mount
if we already have one referral mounted.
>
> Still trying to figure what has caused this.
>
So, it's possible this is a readdir problem of some variety. Can you
get a packet dump of the sequence? That would help a lot.
Daniel
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org