On 12/11/13 11:09, Chuck Lever wrote: >> In the past, if admins want rpc.gssd in the mount path they had to configure it. >> > Now we are silently adding, yet another, daemon to the mount path and if >> > rpc.gssd starts falling on its face, I think it will be difficult to debug, >> > since the daemon is not expected to be there... > Our only real choice here is to fix gssd. Anything else is punting the problem down the road. > No. The last there was a daemon was involved in all NFS client mounts (at least that I can remember) was when lockd was a user level daemon. The main reason it was ported to the kernel was to get ride of the bottle neck it caused... Now we adding similar bottle neck back?? Architecturally, put a daemon in the direct NFS mount path just does not make sense... IMHO... steved. -- 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
