Editing Ploop/Why
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 1: | Line 1: | ||
| − | + | This articles tries to summarize why ploop is needed, and why is it a better technology. | |
| − | |||
| − | This | ||
| − | == Before ploop == | + | == Before ploop == |
| − | |||
First of all, a few facts about the pre-ploop era technologies and their | First of all, a few facts about the pre-ploop era technologies and their | ||
limitations. | limitations. | ||
| − | |||
As you are probably aware, a container file system was just a directory | 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 | 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. | seems like a good and natural idea, there are a number of limitations. | ||
| − | |||
<ol> | <ol> | ||
<li>Since containers are living on one same file system, they all | <li>Since containers are living on one same file system, they all | ||
| − | share common properties of that file system ( | + | share common properties of that file system (it's type, block size, |
| − | and other options). That means we | + | and other options). That means we can not configure the above properties |
on a per-container basis.</li> | on a per-container basis.</li> | ||
| − | |||
<li>One such property that deserves a special item in this list is | <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 | file system journal. While journal is a good thing to have, because | ||
| Line 30: | Line 24: | ||
file truncates), all the other containers I/O will block waiting | file truncates), all the other containers I/O will block waiting | ||
for the journal to be written to disk. In some extreme cases we saw | for the journal to be written to disk. In some extreme cases we saw | ||
| − | up to 15 seconds of such blockage | + | up to 15 seconds of such blockage.</li> |
| − | |||
| − | + | <li>There is no such thing as a per-directory disk quota for Linux, | |
| − | <li> | + | so in order to limit containers disk space we had to develop one, |
| − | in order to limit containers disk space we had to develop | + | it's called vzquota.</li> |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
<li>When doing a live migration without some sort of shared storage | <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 | (like NAS or SAN), we sync the files to a destination system using | ||
| Line 59: | Line 37: | ||
those apps are not surviving the migration</li> | those apps are not surviving the migration</li> | ||
| − | |||
<li>Finally, a container backup or snapshot is harder to do because | <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> | there is a lot of small files that need to be copied.</li> | ||
</ol> | </ol> | ||
| − | == Introducing ploop == | + | == Introducing ploop == |
| − | |||
In order to address the above problems and ultimately make a world a better | 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 | place, we decided to implement a container-in-a-file technology, not | ||
| Line 72: | Line 48: | ||
as effectively as all the other container bits and pieces in OpenVZ. | 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 | 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 | device, and create and use a file system on that device. Some readers | ||
| Line 80: | Line 55: | ||
is very limited. | is very limited. | ||
| − | === Modular design === | + | === Modular design === |
| − | |||
Ploop implementation in the kernel have a modular and layered 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 | The top layer is the main ploop module, which provides a virtual block | ||
device to be used for CT filesystem. | device to be used for CT filesystem. | ||
| − | |||
The middle layer is the format module, which does translation of | The middle layer is the format module, which does translation of | ||
block device block numbers into image file block numbers. A simple format | block device block numbers into image file block numbers. A simple format | ||
| Line 97: | Line 70: | ||
data stored in the container. | data stored in the container. | ||
| − | |||
It is also possible to support other image formats by writing other | 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). | 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 | 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 | on an ext4 device, and for NFS are available. There are plans to also | ||
| Line 108: | Line 79: | ||
in the VFS layer which is still being worked on. | in the VFS layer which is still being worked on. | ||
| − | === | + | == Benefits == |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | • 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 | * Large-size image files I/O instead of lots of small-size files I/O on management operations | ||
| − | + | • Disk quota can be implemented based on virtual device sizes. No need for sub-tree quotas | |
| − | + | •Live backup is easy and consistent | |
| − | + | •Live migration is reliable and efficient | |
| − | + | •Different containers may use file systems of different types and properties | |
| − | + | •No need to limit “number-of-inodes-per-container | |
| − | |||
In addition: | In addition: | ||
| − | * [Potential] support for QCOW2 and other image formats | + | * Efficient container creation |
| − | + | • [Potential] support for QCOW2 and other image formats | |
| − | + | • Support for different storage types | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
