> ~ 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(a)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(a)lists.nfs-ganesha.org
To unsubscribe send an email to support-leave(a)lists.nfs-ganesha.org