On Mar 4, 2012, at 9:17 PM, Harshula wrote: > On Tue, 2012-02-28 at 10:50 -0500, Chuck Lever wrote: >> On Feb 28, 2012, at 9:35 AM, Chuck Lever wrote: > >>> My comment is that if the text in the TRANSPORT METHODS section in >> nfs(5) about UDP reassembly is not adequate it should be updated. I >> would rather see the meat of the proposed text merged into that >> section; otherwise we have two disparate sections discussing the same >> topic. That section is where this kind of discussion belongs. > > Good point. I'll try to massage the text into that section. Thanks. >> A few more comments. >> >> Any file, including a /proc file, called out in new text should be >> added to the FILES section, IMO. >> >> If we can't resolve the provenance issue, someone could rewrite the >> patch from scratch so that it addresses the review comments. > > We now know who authored (Olaf Kirch) and committed (Mads Martin > Joergensen) the text at SUSE. Do we need to get a sign-off from someone > at SUSE? IMO if Olaf is still there, he can send a SOB. But IANAL. >> I don't agree with adding in-code warnings. Mount works silently >> unless it fails, and this is not a mount failure. Would such warnings >> ever be seen for NFS mounts added to /etc/fstab, or performed by >> automounter? I think by and large most people type "mount -t nfs" >> without options and will get our current default transport setting, >> which is TCP, or UDP if the server does not support TCP. Isn't that >> adequate? >> >> We also know that the risk of using UDP is mitigated by using jumbo >> frames, specifying a small r/wsize, or by reducing the fragment >> reassembly timeout. If an admin does those things, she still gets the >> warning. >> >> It seems needlessly alarmist, and useless for our most common use >> cases. > > Sounds reasonable. Just the man page text then. -- Chuck Lever chuck[dot]lever[at]oracle[dot]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
