All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Durgin <josh.durgin@inktank.com>
To: Mike Ryan <mike.ryan@inktank.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: PG recovery reservation state chart
Date: Tue, 02 Oct 2012 13:31:13 -0700	[thread overview]
Message-ID: <506B4F11.5070402@inktank.com> (raw)
In-Reply-To: <20121002194858.GC8206@splice>

On 10/02/2012 12:48 PM, Mike Ryan wrote:
> 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.

Is the local reservation taken in OSD ID order with the remote
reservations as well? What's the difference between local and remote
reservations? Are there different limits on remote and local
reservations?

> 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.

If there's more than one possible replica to backfill from could we try
to reserve others if the first is busy instead of waiting?

Why would a remote backfill reservation fail if the OSD is full (disk 
space)? Backfill doesn't write to the replica, right? Or by full, do
you mean out of reservations?


  parent reply	other threads:[~2012-10-02 20:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-02 19:48 PG recovery reservation state chart Mike Ryan
2012-10-02 20:02 ` Gregory Farnum
2012-10-02 20:21   ` Mike Ryan
2012-10-02 20:31 ` Josh Durgin [this message]
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=506B4F11.5070402@inktank.com \
    --to=josh.durgin@inktank.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=mike.ryan@inktank.com \
    /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.