From: Chris Horn <hornc@cray.com>
To: lustre-devel@lists.lustre.org
Subject: [Lustre-devel] Imperative Recovery - forcing failover server stop blocking
Date: Thu, 18 Jun 2009 18:10:18 -0500 [thread overview]
Message-ID: <4A3AC95A.10302@cray.com> (raw)
Hello lustre-devel,
Some thoughts/questions on one aspect of Imperative Recovery.
Via Eric Barton:
"Actually imperative recovery is just explicit notification of clients
to reconnect and explicit notification of the failover server not to
block for any more clients to reconnect."
Since backup servers immediately begin replay once all clients have
reconnected we only care about the case where we have dead/dying
clients, or maybe when clients are "too slow". In these cases we are
seeking the ability to short circuit the recovery window, however this
is equivalent to simply having a short(er) recovery window in the first
place.
It seems as though an ability to short circuit is only going to be
useful if we can distinguish between the case where we only need a short
recovery window vs. the case where we need that extra time. My question
is, what are the use cases where this applies?
My intuition is the following:
Case 1: x/y clients which are dead, (y-x)/y clients connected to the
backup server (all clients that can connect have done so). We want to
go ahead and short circuit.
Case 2: x/y clients which are dead, (y-x-z)/y clients connected to the
backup server (z slow clients). We want more time for the z slow
clients to connect.
Am I missing a use case? If not then my next question is, do we want to
distinguish between these two cases? If we do want to distinguish
between these two cases, then imperative recovery needs a mechanism to
distinguish between them in addition to the explicit notification of
clients and explicit notification of the failover server.
If we want to treat these cases the same then imperative recovery
reduces to allowing the recovery window timeout to be tunable (if it
isn't already), and the explicit notification of clients to reconnect
(which still nets a huge improvement over the current implementation).
I can imagine having an ability to end a server's recovery window early
might be useful to system admins in some circumstances, but I don't see
its utility in an automated failover solution.
Chris Horn
next reply other threads:[~2009-06-18 23:10 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-18 23:10 Chris Horn [this message]
2009-06-19 21:18 ` [Lustre-devel] Imperative Recovery - forcing failover server stop blocking Johann Lombardi
2009-06-19 22:10 ` Chris Horn
2009-06-22 17:53 ` Eric Barton
2009-06-22 18:21 ` Chris Horn
2009-06-22 19:27 ` Brian Behlendorf
2009-06-23 12:49 ` Eric Barton
2009-06-23 14:53 ` Andreas Dilger
2009-06-23 14:59 ` Chris Horn
2009-06-23 17:20 ` Robert Read
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A3AC95A.10302@cray.com \
--to=hornc@cray.com \
--cc=lustre-devel@lists.lustre.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.