6,534
edits
Changes
nice formatting (up to →Merge
This document explains how to use user-space <code>ploop </code> utility for typical
use-cases.
== Getting help ==
All user-space ploop management operations are available via "<code>ploop</code>"
utility. Run it w/o args to get help:
== Initialize image file ==
In-kernel ploop operates on image files of "<code>raw</code>" or "<code>ploop1</code>" format.
An image file should be created and initialized (entirely in user-space)
before asking in-kernel ploop to start using it.
To create and initialize image file of "<code>ploop1</code>" format:
# ploop init -s 1g -f ploop1 /ploop.image
the same for "<code>raw</code>" format:
# ploop init -s 1g -f raw /ploop.image
where <code>/ploop.image </code> is full path to new image file and 1g is block-device sizeequal to 1GB. These commands succeed only if the file <code>/ploop.image </code> didn'texist at the time of running "<code>ploop init</code>".
== Load modules ==
# modprobe pio_direct
It's not always required to load both <code>pfmt_ploop1 </code> (support of ploop1 format) and<code>pfmt_raw </code> (support of raw format). If we're going to use ploop1 image file,loading <code>pfmt_raw </code> can be omitted. If we're going to use raw image file and have noplans to snapshot it, <code>pfmt_ploop1 </code> can be omitted.
== Create device file ==
Other minors (not multiple of 16) are reserved for partitions. E.g. if primary
partition number 1 is created on <code>/dev/ploop0</code>, <code>/dev/ploop0p1 </code> will have minor
equal to 1.
# ploop mount -f raw -d /dev/ploop0 /ploop.image
Since this point, <code>/dev/ploop0 </code> is operable. One can read/write any data from/to
it (e.g. with "dd"), manipulate partition table on it (with "fdisk"), format
it with <code>mkfs.ext4 </code> and mount it on some mount-point. In the other words, sincenow <code>/dev/ploop0 </code> can be used as any other ordinary block device.
== Snapshot ==
Let <code>/dev/ploop0 </code> be a ploop device running over <code>/ploop.image </code> (i.e. step 4 5 wasdone) and <code>/ploop-delta.image </code> - some full path to non-existent file. Then the
command:
will create empty "ploop1" image file and register it in kernel ploop
forming "snapshotted" configuration <code>top_delta--→ base_delta</code>base_delta where <code>base_delta</code>is <code>/ploop.image </code> and <code>top_delta </code> is <code>/ploop-delta.image</code>.
Since now, all i/o targeted at <code>/dev/ploop0 </code> will change only <code>top_delta</code>.
Actually, while performing snapshot operation in kernel, ploop re-open
<code>base_delta "</code> read-only". So, when "<code>ploop snapshot</code>" is completed, it's quite safe,for example, to backup <code>base_delta</code>.
It's allowable to snapshot snapshotted configuration. Following example above,
# ploop snapshot -d /dev/ploop0 /ploop-delta1.image
will form <code>top_delta-->→ delta--→ base_delta</code>base_delta configuration where:
top_delta := /ploop-delta1.image
All deltas in snapshotted configuration are enumerated in kernel ploop in
the natural order starting from 0 for <code>base_delta</code>:
base_delta' number is 0
