On Sep 1, 2010, at 5:31 PM, Neil Brown wrote: > > Hi, > I was musing about this and thought I would share my musings - not to be > taken too seriously unless they resonate with you. > > If rpc.nfsd is mounting /proc/fs/nfsd, should it also be starting rpc.statd, > which should be running before nfsd is started? > Should it 'exportfs -av' too? > > Should mount.nfs be mounting /var/lib/nfs/rpc_pipefs too? > It already runs statd as requimred, which in-turn runs sm-notify, though it > is really best to run that much earlier. > > How far do we really want to go with this "just do the right thing" approach? > > Should "rpc.nfsd" be a replacement for /etc/init.d/nfs-kernel-server or > whatever your favourite distro calls it? Or should it just be a tool for > managing the nfsd threads? > > > I could imagine that it would be OK to add a '-L' flag to say 'use legacy > interface' and have rpc.nfsd fail noisily if nfsdfs wasn't mounted, and -L > wasn't given. > > I could imagine that if protocol options were specified with -L, that would > be an error. > > And if protocol options are specified which differ from what is currently > in-force, and there are active threads, rpc.nfsd could: > reduce the number of threads to 0 > change the protocol options > restore the number of threads > > > > I think it is (long past) time to deprecate the legacy support in the kernel > at least. I suggest we add a printk to sys_nfsservctl to warn of pending > deprecation, and probably add an entry to > Documentation/feature-removal-schedule.txt. > Aim for removing it all in 2.6.40 ?? and make it a CONFIG option before that. Based on my experience with crabby packagers of nfs-utils, I think a long term plan is a good idea. Warnings of deprecation, for now, is an appropriate first step. And, leaving ample time for people to take the hint is good. .40 gives us a year. .44 gives us two years. Unless it becomes terribly unwieldy, two years is probably a little better, given the glacial rate at which some of the outlying distributions pick up new features. -- 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
