On Sun, Jul 20, 2008 at 2:48 AM, Neil Brown <neilb@xxxxxxx> wrote: > On Saturday July 19, chuck.lever@xxxxxxxxxx wrote: >> > Suppose we were to take this approach: >> > >> > mount.nfs does DNS lookup and portmap look to find IP address and >> > port number. However it *doesn't* send a 'clnt_ping' as >> > probe_port currently does. >> > The information it collects is explicitly given to the kernel with >> > mountproto= mountport= etc. >> > The kernel talks directly to mountd (given proto/addr/port) to get >> > the filehandle and so forth. It doesn't talk to portmap at all >> > if it is given the required port numbers. >> > > ... >> > >> > Thoughts? >> >> Using a connected UDP socket for both the kernel's rpcbind and it's >> mountd client could help in many cases, including, probably, the one >> you mention below, without the need for changing the current >> architecture. >> >> One thing about explicitly specifying mountport and mountproto during >> a mount is that the umount.nfs command may have to include some logic >> to throw those out and reprobe if those settings don't work at unmount >> time. These options were added to allow traversing a firewall using a >> fixed port and protocol; overloading them for the case you describe >> above may perhaps have some unpleasant consequences for the fixed >> port/protocol case. >> > > Yes.... umount wouldn't know the difference between: > - don't use portmap, it doesn't work. Just use this port number. > and > - I used portmap and got this port number, so maybe it will be > useful to you to. > > In the first case umount should only use the mountport given. In the > second case it arguably should not and should always talk to portmap > to get he port number (as it could be much later and mountd may well > be on a different port). > > >> >> > If an NFS server is only listening on TCP for portmap (as apparently >> >> > MS-Windows-Server2003R2SP2 does), mount doesn't cope. There is retry >> >> > logic in case the initial choice of version/etc doesn't work, but it >> >> > doesn't cope with mountd needing tcp. >> >> I think that is mostly because the text-based mount option rewriting >> logic isn't robust yet. I have several patches in the IPv6 series >> that should address some of this. > > Any chance of pulling these out and sending them upstream now? or is > the IPv6 series very close to release? IPv6 is actively being worked on. I expect all these will be available in the next 6 months. However this specific set of patches is dependent on some extensive changes (like, a complete re-implementation of mount's portmap client). Pulling them out now would be a lot of work and I'm not sure it's worth the distraction to the IPv6 effort, which essentially needed to be complete last month. >> But many of Linux's NFS auxiliary services are UDP-only. statd and >> sm-notify, for instance, are UDP-only as far as I can tell. And >> recently the kernel's NLM service was changed to listen only on TCP if >> clients are connecting to servers only via TCP -- and that breaks some >> local Linux services that assume UDP will always be there (like >> SM_MON). > > I'm not so much focussed on "make it work without UDP" as "avoid a > regression". The current code doesn't work in situations where the > old code does work. That is bad. So, it is well known that there are some areas where text-based mounts don't work as well as legacy mounts. The problem is we don't have a anything like a complete requirements specification for NFS mounting (let alone a sophisticated or even simple regression/unit test suite for mount), so it's really quite impossible to expect that a completely new architecture will work out of the box. We do know that the existing legacy ABI is insufficient for many reasons. I don't think any one of us on this list has a complete enough history with mount to know precisely which use cases are the ones we need to carry forward to the text-based mount interface. I've expected some problems in this area, and the only thing I can hope for is that people will diligently report problems. If you have specific problems with the text-based implementation, I'd like to hear about them so we can clear them up as quickly as possible. I never claimed that work is complete yet. > I'd just like to get the regression fixed. Me too. Is it not sufficient to use connected UDP sockets in both user space and the kernel, and fix the kernel to return EPROTONOTSUPP where appropriate? A healing balm for those who would like to use late model nfs-utils releases but don't want the hassle of the remaining bugs in the text-based mounts may be in order. It would be easy to add a configure switch to use only the legacy ABI interface for mount.nfs. -- Chuck Lever -- 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