Konstantin Belousov wrote: >On Tue, Nov 28, 2017 at 02:26:10PM +0100, Emmanuel Vadot wrote: >> On Tue, 28 Nov 2017 13:04:28 +0200 >> Konstantin Belousov <kostik...@gmail.com> wrote: >> >> > On Tue, Nov 28, 2017 at 11:41:36AM +0100, Emmanuel Vadot wrote: >> > > >> > > Hello, >> > > >> > > I would like to switch the vfs.nfsd.issue_delegations sysctl to a >> > > tunable. Since it defaults to "disabled", I don't see why a tunable would be necessary? (Just do nothing and delegations don't happen. If you want the server to issue delegations, then use the sysctl to turn them on. If you want to turn them off again at the server, reboot the server without setting the sysctl.)
> > > The reason behind it is recent problem at work on some on our filer > > > related to NFS. > > > We use NFSv4 without delegation as we never been able to have good > > > performance with FreeBSD server and Linux client (we need to do test > > > again but that's for later). Delegations are almost never useful, especially with Linux clients. [stuff snipped] > > Perhaps make nodeleg per-mount flag ? The sysctl vfs.nfsd.issue_delegations only affects the server. If you have a FreeBSD client that is mounting a delegations enabled server and does not want delegations, just don't run the "nfscbd" daemon on the client. The only time you want the "nfscbd" daemon running is for delegations and pNFS layouts. (I suppose there is the case of a client using NFSv4.1/pNFS against a server with delegations enabled, but since delegations aren't very useful, I'd just disable delegations on the server for this case.) Having a per-mount version of this would be overkill, I think. It would have to disable callbacks on the mount point, since there is no way for a client to say "don't give me delegations" except disabling callbacks, which the server requires for delegation issue. [stuff snipped] The case where there has never been delegations issued will result in an empty delegation queue. Maybe this case can be handled without acquiring the "global NFSv4 state lock", which is what sounds like is causing the performance issue. Maybe a global counter of how many delegations are issued that is handled by atomic ops. --> If it is 0, nfsrv_checkgetattr() can just return without acquiring the lock. I'll take a look at this, rick _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"