Re: Switch vfs.nfsd.issue_delegations to TUNABLE ?

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 <kostikbel_at_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