Changes

<translate>

This article tries to summarize why ploop is needed, and why is it a better technology.

First of all, a few facts about the pre-ploop era technologies and their

limitations.

As you are probably aware, a container file system was just a directory

on the host, which a new container was chroot()-ed into. Although it

seems like a good and natural idea, there are a number of limitations.

<ol>

<li>Since containers are living on one same file system, they all

on a per-container basis.</li>

<li>One such property that deserves a special item in this list is

file system journal. While journal is a good thing to have, because

up to 15 seconds of such blockage.</li>

<li>Since many containers share the same file system with limited space,

in order to limit containers disk space we had to develop per-directory

disk quotas (i.e. vzquota).</li>

<li>Since many containers share the same file system, and the number

of inodes on a file system is limited [for most file systems], vzquota

basis.</li>

<li>In order for in-container (aka second-level) disk quota

(i.e. standard per-user and per-group UNIX dist quota) to work,

to work.</li>

<li>When doing a live migration without some sort of shared storage

(like NAS or SAN), we sync the files to a destination system using

those apps are not surviving the migration</li>

<li>Finally, a container backup or snapshot is harder to do because

there is a lot of small files that need to be copied.</li>

</ol>

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

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

is very limited.

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

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

in the VFS layer which is still being worked on.

Write tracker is a feature of ploop that is designed for live migration. When write tracker is turned on, the kernel memorizes a list of modified data blocks. This list then can be used to efficiently migrate a ploop device to a different physical server, with minimal container downtime. User-space support for this is implemented in '''ploop copy''' tool and is used by '''vzmigrate''' utility.

The idea is to do iterative migration of an image file, in the following

way:

# Freeze the container processes and repeat steps 3 and 4 last time.

See [http://openvz.livejournal.com/41835.html Effective live migration with ploop write tracker] blog post for more details.

With ploop, one can instantly create file system snapshots. Snapshots are described in [http://openvz.livejournal.com/44508.html ploop snapshots and backups] blog post.

* File system journal is not bottleneck anymore

* Large-size image files I/O instead of lots of small-size files I/O on management operations

* Different containers may use file systems of different types and properties

In addition:

* Efficient container creation

* Support for different storage types

* [[Ploop]]

</translate>

[[Category: Storage]]