On Mon, Mar 01, 2010 at 07:57:28AM -0500, Steve Dickson wrote: > On 02/22/2010 01:22 PM, J. Bruce Fields wrote: > > On Sat, Feb 20, 2010 at 03:45:10PM -0800, Trond Myklebust wrote: > >> From: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > >> > >> Fix a typo in commit 6d5ac3fa (nfsd: Disble NFS 4.1 functionality by default). > > > > Better: please just rever 6d5ac3fa and apply > > http://marc.info/?l=linux-nfs&m=126540028610022&w=2 > The problem I saw with the this patch was it would take > a code change to re-enable the 4.1 functional, Enabling 4.1 will require no code changes to nfs-utils, only to the kernel. (But it will require a lot of code changes to nfs-utils, as we should complete 4.1 support first.) > verses a > enabling a configuration flag. Plus, there has been a > precedence set of having these types of configuration flags, > note the enable_nfsv3, enable_nfsv4, so adding a enable_nfsv41 > seem to me made sense... > > > > > - distributions shouldn't be turning on 4.1 by default yet. > Its not... If the --enable_nfsv41 is not set, the 4.1 functional is > off. Having this type of flag enables the distros to enable the > functionality on development kernels but disable it on stable So you want to enable it (for example) in Fedora, but disable it in RHEL? I don't think that's a good idea. If servers running current Fedora kernels are still around when the client starts trying 4.1 first, then we'll run into trouble. --b. > kernels, without any additional patches. Again to me, its seems > like the cleanest way to do it... > > > - In addition to the bug Trond found, 6d5ac3fa also > > inadvertently disables -N4 in the disable_nfsv41 case. > Fixed... > > 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
