src/ceph/doc/dev/osd_internals/pg_removal.rst

   1 ==========
   2 PG Removal
   3 ==========
   4
   5 See OSD::_remove_pg, OSD::RemoveWQ
   6
   7 There are two ways for a pg to be removed from an OSD:
   8
   9   1. MOSDPGRemove from the primary
  10   2. OSD::advance_map finds that the pool has been removed
  11
  12 In either case, our general strategy for removing the pg is to
  13 atomically set the metadata objects (pg->log_oid, pg->biginfo_oid) to
  14 backfill and asynronously remove the pg collections.  We do not do
  15 this inline because scanning the collections to remove the objects is
  16 an expensive operation.
  17
  18 OSDService::deleting_pgs tracks all pgs in the process of being
  19 deleted.  Each DeletingState object in deleting_pgs lives while at
  20 least one reference to it remains.  Each item in RemoveWQ carries a
  21 reference to the DeletingState for the relevant pg such that
  22 deleting_pgs.lookup(pgid) will return a null ref only if there are no
  23 collections currently being deleted for that pg.
  24
  25 The DeletingState for a pg also carries information about the status
  26 of the current deletion and allows the deletion to be cancelled.
  27 The possible states are:
  28
  29   1. QUEUED: the PG is in the RemoveWQ
  30   2. CLEARING_DIR: the PG's contents are being removed synchronously
  31   3. DELETING_DIR: the PG's directories and metadata being queued for removal
  32   4. DELETED_DIR: the final removal transaction has been queued
  33   5. CANCELED: the deletion has been canceled
  34
  35 In 1 and 2, the deletion can be canceled.  Each state transition
  36 method (and check_canceled) returns false if deletion has been
  37 canceled and true if the state transition was successful.  Similarly,
  38 try_stop_deletion() returns true if it succeeds in canceling the
  39 deletion.  Additionally, try_stop_deletion() in the event that it
  40 fails to stop the deletion will not return until the final removal
  41 transaction is queued.  This ensures that any operations queued after
  42 that point will be ordered after the pg deletion.
  43
  44 OSD::_create_lock_pg must handle two cases:
  45
  46   1. Either there is no DeletingStateRef for the pg, or it failed to cancel
  47   2. We succeeded in canceling the deletion.
  48
  49 In case 1., we proceed as if there were no deletion occurring, except that
  50 we avoid writing to the PG until the deletion finishes.  In case 2., we
  51 proceed as in case 1., except that we first mark the PG as backfilling.
  52
  53 Similarly, OSD::osr_registry ensures that the OpSequencers for those
  54 pgs can be reused for a new pg if created before the old one is fully
  55 removed, ensuring that operations on the new pg are sequenced properly
  56 with respect to operations on the old one.