On Apr. 02, 2009, 17:31 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Thu, Apr 02, 2009 at 10:25:55AM -0400, Trond Myklebust wrote: >> On Thu, 2009-04-02 at 10:22 -0400, J. Bruce Fields wrote: >>> On Thu, Apr 02, 2009 at 10:16:40AM -0400, Trond Myklebust wrote: >>>> On Thu, 2009-04-02 at 16:46 +0300, Benny Halevy wrote: >>>>> On Apr. 02, 2009, 16:27 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: >>>>>> On Thu, Apr 02, 2009 at 12:18:46PM +0300, Benny Halevy wrote: >>>>>>> On Apr. 01, 2009, 18:32 +0300, Benny Halevy <bhalevy@xxxxxxxxxxx> wrote: >>>>>>>> On Apr. 01, 2009, 17:07 +0300, Benny Halevy <bhalevy@xxxxxxxxxxx> wrote: >>>>>>>>> On Apr. 01, 2009, 16:10 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: >>>>>>>>>> On Wed, Apr 01, 2009 at 11:31:21AM +0300, Benny Halevy wrote: >>>>>>>>>>> On Apr. 01, 2009, 7:33 +0300, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: >>>>>>>>>>>> On Sat, Mar 28, 2009 at 11:31:09AM +0300, Benny Halevy wrote: >>>>>>>>>>>>> Added CONFIG_NFSD_V4_1 and made it depend upon NFSD_V4 and EXPERIMENTAL >>>>>>>>>>>>> Indicate that CONFIG_NFS_V4_1 is for NFS developers at the moment >>>>>>>>>>>> Stupid question: do we need CONFIG_NFSD_V4_1 at all? How many people >>>>>>>>>>>> will want to build a kernel with v4.0 but not v4.1? >>>>>>> Bruce, with the patch below in place, would it be reasonable to >>>>>>> remove CONFIG_NFSD_V4_1? >>>>>> It would be fine with me, but perhaps queuing that up as a separate >>>>>> patch for 2.6.31 would be better than doing it at the last moment. >>>>> It's not too hard to get rid of it now. >>>>> I think it might be better than introducing a new config item >>>>> to be removed in the next version. >>>>> >>>>> Trond, please speak up if you want to remove CONFIG_NFS_V4_1 as well. >>>>> On the client side minorversion 1 will be used only if the user >>>>> explicitly asked for it with mount -o minorversion=1. >>>> I'd feel more comfortable with being able to compile it out until the >>>> stability of the code has been established. I'd certainly want to be >>>> able to do that on the server side, since it has no other means to >>>> restrict the protocol version should it turn out that NFSv4.1 has some >>>> fatal condition. >>> I think it's acceptable given an interface that allows choosing the >>> supported minorversion at runtime (and that defaults 4.1 to off). >> Is there such an interface on the server? > > That's the patch Benny just posted. It seems like a pretty simple > extension of the existing version-choosing interface > (/proc/fs/nfsd/versions), though I think the version he posted defaults > 4.1 to on? I need to take another look. That's right. This can be changed trivially, but I'll have to find and work the reason why the settings reset on service nfs restart, otherwise it will reset itself. Benny > > --b. > _______________________________________________ > pNFS mailing list > pNFS@xxxxxxxxxxxxx > http://linux-nfs.org/cgi-bin/mailman/listinfo/pnfs -- 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
