>> ~ 90 seconds for the nfs-ganesha stop

Why is this taking 90 seconds? We should fix this.

>> ~ 60 seconds for an nfs client to resume

There are 2 things here. NFS clients by default use 60 seconds retry timeout. You can use a lesser timeout (it is in deci-seconds) with a mount option "timeo". Also, if you don't use NLM (or you use local_lock=all in all of your clients), you can run Ganesha in graceless mode provided you don't have Windows NFS clients.

On Wed, Apr 15, 2020 at 11:34 PM Frank Filz <ffilzlnx@mindspring.com> wrote:

> My environment:
>
> # nfs-ganesha-2.8.3-4.el7.x86_64
> # CentOS Linux release 7.7.1908 (Core)
>
>
> In light of the stability problems that I've reported here recently, and given that I
> really do want to continue to use nfs-ganesha, I'm considering mitigating
> problems by either periodic or on-demand restarts of the nfs-ganesha service.
>
> A complete nfs-ganesha restart, until an nfs client is successfully accessing the
> server again, consistently takes:
>
> ~ 90 seconds for the nfs-ganesha stop

Others should chime in too, but you may be able to speed this up with SIGKILL instead of SIGTERM.

We also need to work to speed SIGTERM shutdown...

> ~ 2 seconds for the nfs-ganesha start
> ~ 60 seconds for an nfs client to resume

Depending on how reliant you are on byte range locks and NFS v4 open (really only critical if you interop with Samba or Windows NFS v4 clients, otherwise *ix Open state just includes access mode and no deny mode), you could reduce the grace period and lease period. Ability to do that may also depend on your network.

> for a total of about 2.5 minutes.
>
> Do these times indicate a problem or is this normal behaviour for nfs-ganesha?
>
> If these times are normal and not the result of some problem, is there any way
> to safely decrease this restart time?
>
> Thanks,
> Todd

Frank
_______________________________________________
Support mailing list -- support@lists.nfs-ganesha.org
To unsubscribe send an email to support-leave@lists.nfs-ganesha.org