Zach Brown 9ebc9d0f66 Manage client reconnect delay ...

The client currently always queues immediate connect work if it's
nodify_down is called.  It was assuming that notify_down is only called
from a healthy established connection.   But it's also called for
unsuccessful conneect attempts that might not have timed out.  Say the
host is up but the port isn't listening.

This results in spamming connection attempts while an old stale leader
block until a new server is elected, fences the previous leader, and
updates their quorum block.

The fix is to explicitly manage the connection work queueing delay.  We
only set it to immediately queue on mount and when we see a greeting
reply from the server.  We always set it to a longer timeout as we start
a connection attempt.  This means we'll always have a long reconnect
delay unless we really connected to a server.

Signed-off-by: Zach Brown <zab@versity.com>

2021-05-26 14:18:28 -07:00

..

src

Manage client reconnect delay

2021-05-26 14:18:28 -07:00

.gitignore

scoutfs: update rpm building infrastructure

2018-09-14 15:07:10 -07:00

Makefile

Filesystem version instead of format hash check

2021-01-15 10:53:00 -08:00

scoutfs-kmod.spec.in

scoutfs: update rpm building infrastructure

2018-09-14 15:07:10 -07:00