On Oct 21, 2013, at 7:54 PM, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: > On 10/21/2013 04:44 PM, Weston Andros Adamson wrote: >> >> On Oct 21, 2013, at 5:32 PM, Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote: >> >>> So, the problem I reported earlier with failing to unmount was fixed >>> by the back-ported patch. >>> >>> Now, another problem is reported by my user. In this case, they are >>> trying to mount an IPv6 NFS server using NFSv3. Kernel is 3.9.11+, >>> with patches to support binding mount points to local IP (v4/v6) addresses. >>> >>> Some NFS over IPv6 mounts work fine, but some do not. A reboot of the >>> NFS client machine did not fix the problem. >>> >>> I have tried to reproduce the problem locally, but so far everything works fine >>> for us. >>> >>> From my own app's logs: >>> >>> # mount -t nfs [4001:1::1:1]:/vol/vol1 /mnt/lf/RDnfse11c0 -o srcaddr=4001:1::1:201,vers=3 >>> # requested NFS version or transport protocol is not supported >>> >>> When this problem happens, I do not see any network traffic when trying to mount. >> >> Did you look for the mount protocol when getting a network trace (filter "rpc" in wireshark). > > I saw zero NFS related packets on the wire when hitting this problem. > But, there could have been packets earlier that put it into a funky > state, or a bit less likely, they could have been going out some of the > other virtual interfaces on the system. Ok, I wanted to make sure you weren't just looking at port 2049... > >> Could you: >> >> 1) run "rpcdebug -m nfs -s mount" before mounting, post output of dmesg after mount fails. >> >> 2) add -v to the mount command and post the output > > I can try this. > >> 3) maybe get rid of srcaddr= option / post info about the ip configuration > > I can't easily do this, as the user's setup requires the srcaddr to route properly > to the filer. I just want to make sure it's not a configuration error, but the outputs of 1) and 2) will help us determine what's happening. > > I am also going to run a kernel with printks added around all the EOPNOTSUPP > returns that I can find to try to track down what part of the kernel is > complaining. The rpcdebug part should help with that. Maybe you should turn on everything (rpcdebug -m nfs -s all) since it's just a (failed) mount. -dros > > Thanks, > Ben > > > -- > Ben Greear <greearb@xxxxxxxxxxxxxxx> > Candela Technologies Inc http://www.candelatech.com > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
