Volumes and snapshots

This document provides basic information about how volumes and snapshots work:

Volumes are the basic service of the StorPool storage system. They appear to storage clients as block devices under the /dev/storpool/ directory and behave as normal disk devices.
Snapshots in StorPool are read-only point-in-time images of volumes.

Volumes and snapshots can be managed in the following ways:

Using the command line interface; for details, see Volumes and Snapshots.
Using the REST API.
You can generate a visual representation of the volumes and snapshots; for details, see StorPool tree.

Volumes

Volumes are the basic service of the StorPool storage system. A volume always has a name, a global ID and a certain size. It can be read from and written to. It could be attached to hosts as read-only or read-write block device under the /dev/storpool directory (available as well at /dev/storpool-byid).

The volume name is a string consisting of one or more of the allowed characters - upper and lower Latin letters (a-z,A-Z), numbers (0-9) and the delimiters dot (.), colon (:), dash (-) and underscore (_).

Creating a volume

All volumes are thin provisioned. Creating a volume is not limited to physical disk or disk pool size. Creating a volume doesn’t pre-allocate physical space in the storage cluster.

Here is an example how you can create a volume using the CLI:

# storpool volume testvolume create size 100G template ssd

For details, see Creating a volume.

Deleting a volume

Here is an example how you can delete a volume using the CLI:

# storpool volume vol1 delete vol1

For details, see Deleting volumes.

Renaming a volume

Here is an example how you can rename a volume using the CLI:

# storpool volume testvolume update rename newvolume

For details, see Renaming volumes.

Resizing a volume

Here is an example how you can resize a volume using the CLI:

# storpool volume testvolume update size +1G

For details on volume enlargement and shrinkage, see Resizing volumes.

Snapshots

Snapshots are read-only point-in-time images of volumes. They are created once and their data cannot be modified. They can be attached to hosts as read-only block devices under /dev/storpool.

All volumes and snapshots share the same name-space. Names of volumes and snapshots are unique within a StorPool cluster. This means you can’t have a volume and a snapshot with the same name.

This diagram illustrates the relationship between a snapshot and a volume:

Volume snapshot relation — Volume-snapshot relation

When you create a snapshot snap1 of volume vol1, this volume becomes based on the snapshot.
vol1 contains only the changes since snap1 was taken. In the common case this is a small amount of data.
Arrows indicate a child-parent relationship. Each volume or snapshot may have exactly one parent which it is based upon.
Writes to vol1 are recorded within the volume.
When there is a request for reading from vol1 the system reads data from the volume or from the parent snapshot snap1, depending on whether the data has been changed since the snapshot was created.

Snapshots and volumes are completely independent. Each snapshot may have many children (volumes and snapshots). Volumes cannot have children. This is illustrated in the diagram below:

Volume snapshot chain — Volume-snapshot chain

snap1 contains a full image.
snap2 contains only the changes since snap1 was taken.
vol1 and vol2 contain only the changes since snap2 was taken.

Creating a snapshot of a volume

Assume there is a volume named vol1.

After the first snapshot the state of vol1 is recorded in a new snapshot named snap1. vol1 does not occupy any space now, but will record any new writes which come in after the creation of the snapshot. Reads from vol1 may fall through to snap1.

Then the state of vol1 is recorded in a new snapshot named snap2. snap2 contains the changes between the moment snap1 was taken and the moment snap2 was taken. snap2’s parent is the original parent of vol1.

Here is an example how you can create a snapshot using the CLI:

# storpool volume vol1 snapshot snap1

For details, see Creating snapshots.

Creating a volume based on an existing snapshot (cloning)

Before the creation of vol1 there is a snapshot named snap1.

A new volume, named vol1 is created. vol1 is based on snap1. The newly created volume does not occupy any space initially. Reads from the vol1 may fall through to snap1 or to snap1’s parents (if any).

Here is an example how you can create a volume based on an existing snapshot using the CLI:

# storpool volume vol1 parent snap1

For details, see Volume operations.

Deleting a snapshot

vol1 and vol2 are based on snap1. snap1 is based on snap0. snap1 contains the changes between the moment snap0 was taken and when snap1 was taken. vol1 and vol2 contain the changes since the moment snap1 was taken.

After the deletion, vol1 and vol2 are based on snap1’s original parent (if any). In the example they are now based on snap0. When deleting a snapshot, the changes contained therein will not be propagated to its children and StorPool will keep the snap1 in deleting state to prevent from an explosion of disk space usage.

Here is an example how you can delete a snapshot using the CLI:

# storpool snapshot snap1 delete snap1

For details, see Deleting snapshots.

Rebase to null (promotion)

vol1 is based on snap1. snap1 is in turn based on snap0. snap1 contains the changes between the moment snap0 was taken and when snap1 was taken. vol1 contains the changes since the moment snap1 was taken.

After promotion vol1 is not based on a snapshot. vol1 now contains all data, not just the changes since snap1 was taken. Any relation between snap1 and snap0 is unaffected.

Here is an example how you can promote a snapshot using the CLI:

# storpool snapshot testsnap rebase # [parent-snapshot-name]

For details, see Promoting snapshots.

Rebase

vol1 is based on snap1. snap1 is in turn based on snap0. snap1 contains the changes between the moment snap0 was taken and when snap1 was taken. vol1 contains the changes since the moment snap1 was taken.

After the rebase operation vol1 is based on snap0. vol1 now contains all changes since snap0 was taken, not just since snap1. snap1 is unchanged.

For details on how you can do this on the command line, see Promoting snapshots.

Example use of snapshots

This is a semi-realistic example of how volumes and snapshots may be used:

There is a snapshot called base.centos7. This snapshot contains a base VM image (in this example, CentOS 7), which was prepared carefully by the service provider.
There are 3 customers with 4 virtual machines each.
All virtual machine images are based on the same ‘master’ image, but may contain custom data, which is unique to each VM. Changes in one volume don’t affect the parent snapshots or the other volumes that are created from it.

This example shows another typical use of snapshots - for restore points back in time for this volume.

There is one base image for CentOS 7, three snapshot restore points and one live volume cust123.v.1