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?
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
