On Fri, 2017-02-24 at 16:44 -0500, J. Bruce Fields wrote: > On Fri, Feb 24, 2017 at 04:34:24PM -0500, Jeff Layton wrote: > > On Fri, 2017-02-24 at 16:25 -0500, J. Bruce Fields wrote: > > > The one other minor thing we could do is skip adding the UDP listener > > > entirely in the v4-only case. I think that's a job for rpc.nfsd? > > > > > > --b. > > > > > > > Yeah I think we'd need to fix that in rpc.nfsd. > > > > Maybe it's time to just start doing having it do TCP-only by default > > anyway? Make it so you have to explicitly enable UDP listeners if you > > want them? Does anyone seriously run NFS over UDP these days for > > anything other than interop testing? :) > > I thought I remembered somebody floating this on linux-nfs a couple > years ago and finding there were still a couple vocal users. Or maybe > that was NFSv2. I can't find the thread now. > > I'm pretty conservative about anything that might break people's ancient > but working setups on upgrade, but maybe it's time. > > Just switching the default to off in nfs-utils first would be the way to > go, I think, then if that goes well we could think about phasing out > kernel support. > > --b. > Ok, I posted a patch a couple of days ago as an RFC. It's pretty straightforward and works. I don't see any need to turn off kernel support just yet. If we do have users who need it, turning it back on is pretty trivial with nfs.conf. What I'd really like is to eventually have distros move to a default nfsd configuration that is v4-only. Have the kernel only listen for v4 calls on TCP, turn off lockd and statd, and make mountd not open any IP sockets. What we'd need to make that happen, I think is a [global] stanza in nfs.conf with a single 'nfsd_v3' boolean that defaults to off. If someone needs to serve v3, they could turn that on and everything would be reenabled. That would take a bit of plumbing through various daemons though. -- Jeff Layton <jlayton@xxxxxxxxxx> -- 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
