From: Mike Ryan <mike.ryan@inktank.com>
To: ceph-devel@vger.kernel.org
Subject: PG recovery reservation state chart
Date: Tue, 2 Oct 2012 12:48:58 -0700 [thread overview]
Message-ID: <20121002194858.GC8206@splice> (raw)
[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]
Tried sending this earlier but it seems the list doesn't like PNGs.
dotty or dot -Tpng will make short work of the .dot file I've attached.
These are the changes to the Active state of the PG state chart in order
to support recovery reservations. This is Important Stuff, so please
criticize mercilessly.
Here's a prose version:
When the PG activates, it determines whether it needs to do recovery. If
it does, it grabs its local reservation, then grabs a remote reservation
from each replica in order of OSD ID (to prevent deadlock). Once all
remotes are reserved, it starts recovering.
After recovery, all remote reservations are dropped. If no backfill is
necessary, the local reservation is dropped and we jump to Clean.
If we need to backfill, we request a remote backfill reservation from
the replica. If this reservation is rejected (due to the OSD being too
full) we drop our local reservation and wait for a while in
NotBackfilling. We then grab our local reservation and try again on the
remote reservation. Once we have the remote reservation, we backfill.
After Backfilling we drop the local and remote backfill reservation and
jump to Clean.
[-- Attachment #2: pg_recovery_reservation.dot --]
[-- Type: text/plain, Size: 876 bytes --]
digraph G {
Activating -> Clean [label="AllReplicasClean"];
Activating -> LocalReserving [label="DoRecovery"];
LocalReserving -> WaitRemoteRecoveryReserved [label="LocalRecoveryReserved"];
WaitRemoteRecoveryReserved -> WaitRemoteRecoveryReserved [label="RemoteReserved"];
WaitRemoteRecoveryReserved -> Recovering [label="AllRemotesReserved"];
Recovering -> Clean [label="AllReplicasClean"];
Recovering -> WaitRemoteBackfillReserved [label="RequestBackfill"];
WaitRemoteBackfillReserved -> NotBackfilling [label="RemoteReservationRejected"];
NotBackfilling -> WaitLocalBackfillReservation [label="RequestBackfill"];
WaitLocalBackfillReservation -> WaitRemoteBackfillReserved [label="LocalBackfillReserved"];
WaitRemoteBackfillReserved -> Backfilling [label="RemoteBackfillReserved"];
Backfilling -> Clean [label="Backfilled"];
}
next reply other threads:[~2012-10-02 19:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-02 19:48 Mike Ryan [this message]
2012-10-02 20:02 ` PG recovery reservation state chart Gregory Farnum
2012-10-02 20:21 ` Mike Ryan
2012-10-02 20:31 ` Josh Durgin
2012-10-02 20:40 ` Mike Ryan
2012-10-02 20:35 ` Tommi Virtanen
2012-10-02 20:42 ` Mike Ryan
2012-10-02 22:00 ` Josh Durgin
2012-10-02 22:39 ` Mike Ryan
2012-10-02 21:36 ` Sage Weil
2012-10-02 21:43 ` Mike Ryan
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=20121002194858.GC8206@splice \
--to=mike.ryan@inktank.com \
--cc=ceph-devel@vger.kernel.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.