On Thu, Dec 08 2016, "J. Bruce Fields" <bfields@xxxxxxxxxx> wrote: > On Wed, Dec 07, 2016 at 09:44:25AM -0500, Steve Dickson wrote: >> > >> > I do wonder if this is ever valid though. Why do we allow minor >> > versions to be enabled/disabled? >> IDK... I think Trond did this... you know... >> when in doubt... blame Trond! 8-) > > Or Benny, 8daf220a6a83 "nfsd41: control nfsv4.1 svc via > /proc/fs/nfsd/versions". > >> > Does it make any sense to enable a non-contiguous set of minor versions? >> I don't think so... Talk about handing people rope! ;-) > > I can't think of a reason either. > >> > Should we just have a maximum NFSv4 minor version? >> Maybe.. > > If you do that then I'd allow a minimum too. Why? I'm trying to understand why you would ever want to turn disable a particular minor version. I could equally well ask myself "why specify a maximum"... Benny's patch only suggests that it removes the need for CONFIG_NFSD_V4_1, but why was that needed? Maybe it is just to disable buggy code if some version is found to have an inconvenient bug? The client, by default, tries 4.2, then 4.1, then 4.0. Older clients might start elsewhere. So just disabling unreliable versions individually does seem to make sense. I note that Benny's original patch disabled v4.1 by default, and required it to be explicitly enabled. The current kernel enables all by default, and requires them be explicitly disabled is required. My current nfs.conf code will disabled unwanted minor versions, but not enable any that are already disabled ... I guess I could fix that. .... it is a shame that we can only enable/disable minor versions when there are no nfsd threads running. The justification for failing if nfsd is active is fairly lame, and only applies to major versions. If minor versions could be changed at any time, then it could be a simple function of rpc.nfsd, and the config file would never need to enable things, only disable them. Is there any other reason to disable minor versions, other than to avoid buggy code (either in server or client)?? Actually.... I have a related question that I keep meaning to ask, but haven't. What are the circumstances where NFSv3 should be preferred over NFSv4 (assuming up-to-date kernels on server and client)? I can think of: - NFSv3 is safer if you might need to support loop-back mounts as I don't think NFSv4 state management can reliably make forward progress against memory pressure. In particular, creating the state-manager thread can deadlock waiting for an NFS write. - If you want fast-failover from one server to another, NFSv3 is probably faster as it only imposes the grace-time on lock requests. NFSv4 imposes it on OPEN and so READ/WRITE as well. - NFSv3 is preferred if (for some weird reason) you need to use UDP. Are there any others? Are there any similar reasons to prefer a smaller NFSv4 minor version over a larger one? Thanks, NeilBrown > > --b. > >> > I was trying to duplicate the current functionality as closely as >> > convenient. That might not be best in this case. >> You did a good job... this is definitely a nit. >> >> steved. >>
Attachment:
signature.asc
Description: PGP signature
