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.
BTW, the 'new' cache has was added during 2.5 - definitely before Jan 2003.
So the old stuff really is quite old now.
NeilBrown
--
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
