6,534
edits
Changes
ploop intro and modular design
there is a lot of small files that need to be copied.</li>
</ol>
== Introducing ploop ==
In order to address the above problems and ultimately make a world a better
place, we decided to implement a container-in-a-file technology, not
different from what various VM products are using, but working
as effectively as all the other container bits and pieces in OpenVZ.
The main idea of ploop is to have an image file, use it as a block
device, and create and use a file system on that device. Some readers
will recognize that this is exactly what Linux loop device does!
Right, the only thing is loop device is very inefficient (say, using
it leads to double caching of data in memory) and its functionality
is very limited.
== Modular design ===
Ploop implementation in the kernel have a modular and layered design.
The top layer is the main ploop module, which provides a virtual block
device to be used for CT filesystem.
The middle layer is the format module, which does translation of
block device block numbers into image file block numbers. A simple format
module which is called "raw" is doing trivial 1:1 translation, same as
existing loop device. More sophisticated format module is keeping the
translation table and is able to dynamically grow and shrink the image
file. That means, if you create a container with 2GB of disk space,
the image file size will not be 2GB, but less -- the size of the actual
data stored in the container.
It is also possible to support other image formats by writing other
ploop format modules, such as the one for QCOW2 (used by QEMU and KVM).
The bottom layer is the I/O module. Currently modules for direct I/O
on an ext4 device, and for NFS are available. There are plans to also
have a generic VFS module, which will be able to store images on any
decent file system, but that needs an efficient direct I/O implementation
in the VFS layer which is still being worked on.
