The Ceph Blog

Ceph blog stories provide high-level spotlights on our customers all over the world

June 27, 2018

New in Mimic: Simplified RBD Image Cloning

Motivation

In previous Ceph releases, to create a clone of an image one must first create a snapshot and then mark the snapshot as protected before attempting to clone:

$ rbd snap create parent@snap
$ rbd snap protect parent@snap
$ rbd clone parent@snap clone

This was a necessary evil to ensure RBD performed the proper book-keeping to prevent the removal of a snapshot that had associated clones while only requiring read-only access to the parent image pool. As an additional consequence, this book-keeping required the “rbd snap unprotect” operation to scan *all* pools in the Ceph cluster to ensure that the image was not in-use. Attempting to remove a protected snapshot or unprotect an in-use snapshot would result in an error:

$ rbd snap rm parent@snap
Removing snap: 0% complete...failed.
rbd: snapshot 'snap' is protected from removal.
$ rbd snap unprotect parent@snap
rbd: unprotecting snap failed: (16) Device or resource busy

The fact that you couldn’t unprotect or remove a snapshot that had associated clones resulted in some quirky workarounds in applications like OpenStack, where snapshots are renamed to indicate they have been deleted from Cinder but cannot yet be deleted from RBD.

Simplifying clones in Mimic

Starting with the Mimic release and the RBD clone v2 feature, it is no longer be necessary to manage snapshot protection status. The usage of clone v2 is controlled via the “rbd default clone format” configuration option which defaults to “auto”, but can be overridden to “1” to force the legacy clone v1 behavior or “2” to force the new clone v2 behavior. The default “auto” setting will automatically utilize clone v2 if the minimum supported client is set to “mimic” or later:

$ ceph osd set-require-min-compat-client mimic

With RBD clone v2 support enabled, image snapshots can be cloned without marking the snapshot as protected because RBD automatically tracks the usage of the snapshot by clones:

$ rbd snap create parent@snap
$ rbd clone parent@snap clone

You can determine which images are using the clone v2 feature if the “op_features” line from “rbd info” contains “clone-parent” or “clone-child”:

$ rbd info parent | grep op_features
      op_features: clone-parent
$ rbd info clone | grep op_features
      op_features: clone-child

An additional feature of clone v2 is that attempting to delete snapshots that are in-use by child clone images will transparently move the snapshot to the trash namespace until they are no-longer in-use:

$ rbd snap ls --all parent
SNAPID NAME SIZE  TIMESTAMP                NAMESPACE 
     4 snap 1 GiB Mon Jun  4 16:27:17 2018 user      
$ rbd snap rm parent@snap
$ rbd snap ls parent
$ rbd snap ls --all parent
SNAPID NAME                                 SIZE  TIMESTAMP                NAMESPACE 
     4 8c468a4b-2478-4824-acfe-664439df47e7 1 GiB Mon Jun  4 13:49:10 2018 trash     

Once the last clone image using a trashed snapshot is removed (or flattened), the no-longer in-use snapshot will automatically be removed from the parent image (pending backport of http://tracker.ceph.com/issues/23398 to a future Mimic point release).

This feature can also be combined with the RBD trash feature introduced in Luminous, where parent images can be moved to the trash and eventually deleted via “rbd trash purge” once the last clone is dissociated from the trashed parent image.

Jason Dillaman

Careers