Ploop/Why - Revision history

208.74.121.106 at 16:40, 5 August 2016

2016-08-05T16:40:43Z

208.74.121.106 at 16:40, 5 August 2016

2016-08-05T16:40:01Z

191.34.249.62: Added disadvantages section

2016-03-06T04:55:45Z

Added disadvantages section

191.34.249.62: Some obs, and removal of non explained "Efficient container creation" (please explain better)

2016-03-06T03:00:10Z

Some obs, and removal of non explained "Efficient container creation" (please explain better)

191.34.249.62 at 02:51, 6 March 2016

2016-03-06T02:51:00Z

Sergey Bronnikov: Marked this version for translation

2015-12-25T22:30:36Z

Marked this version for translation

Sergey Bronnikov: add 'translate' tags

2015-12-25T22:30:04Z

add 'translate' tags

Kir: added to Storage category

2014-01-23T18:58:33Z

added to Storage category

Kir: add link to ploop snapshots and backups; added See also

2013-06-12T02:46:12Z

add link to ploop snapshots and backups; added See also

Kir: /* Introducing ploop */ +snapshots

2012-10-04T10:33:22Z

‎Introducing ploop: +snapshots

@@ Line 18: / Line 18: @@
 <li>Since containers are living on one same file system, they all
 share common properties of that file system (its type, block size,
-and other options). That means we can not configure the above properties
+and other options). That means we cannot configure the above properties
 on a per-container basis.</li>

@@ Line 17: / Line 17: @@
 <ol>
 <li>Since containers are living on one same file system, they all
-share common properties of that file system (it's type, block size,
+share common properties of that file system (its type, block size,
 and other options). That means we can not configure the above properties
 on a per-container basis.</li>

@@ Line 147: / Line 147: @@
 * Support for different storage types
-== See also == <!--T:29-->
+== Disadvantages == <!--T:29-->
 * [[Ploop]]
 </translate>
 [[Category: Storage]]

@@ Line 134: / Line 134: @@
 <!--T:27-->
-* File system journal is not bottleneck anymore
+* File system journal is not bottleneck anymore [if you are not using journal_async_commit mount option yet]
 * Large-size image files I/O instead of lots of small-size files I/O on management operations
 * Disk space quota can be implemented based on virtual device sizes; no need for per-directory quotas
-* Number of inodes doesn't have to be limited because this is not a shared resource anymore (each CT has its own file system)
+* Number of inodes doesn't have to be limited because this is not a shared resource anymore (each CT has its own file system) [but these file systems yet have their own inodes limit]
 * Live backup is easy and consistent
 * Live migration is reliable and efficient
@@ Line 144: / Line 144: @@
 <!--T:28-->
 In addition:
 * [Potential] support for QCOW2 and other image formats
 * Support for different storage types

@@ Line 30: / Line 30: @@
 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
-up to 15 seconds of such blockage.</li>
+up to 15 seconds of such blockage [but can be easily fixed using
 <!--T:7-->
@@ Line 39: / Line 40: @@
 <!--T:8-->
 <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
+of inodes on a file system is limited [but can be increased in fs creation], vzquota
 should also be able to limit inodes on a per container (per directory)
 basis.</li>

@@ Line 1: / Line 1: @@
 <translate>
 This article tries to summarize why ploop is needed, and why is it a better technology.
-== Before ploop ==
+== Before ploop == <!--T:2-->
 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
@@ Line 17: / Line 21: @@
 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
@@ Line 27: / Line 32: @@
 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
@@ Line 36: / Line 43: @@
 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,
@@ Line 42: / Line 50: @@
 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
@@ Line 49: / Line 58: @@
 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>
-== Introducing ploop ==
+== Introducing ploop == <!--T:12-->
 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
@@ Line 60: / Line 71: @@
 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
@@ Line 67: / Line 79: @@
 is very limited.
-=== Modular design ===
+=== Modular design === <!--T:15-->
 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
@@ Line 82: / Line 96: @@
 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
@@ Line 91: / Line 107: @@
 in the VFS layer which is still being worked on.
-=== Write tracker ===
+=== Write tracker === <!--T:20-->
 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:
@@ Line 104: / Line 122: @@
 # 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.
-=== Snapshots ===
+=== Snapshots === <!--T:24-->
 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.
-== Benefits ==
+== Benefits == <!--T:26-->
 * 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
@@ Line 120: / Line 141: @@
 * Different containers may use file systems of different types and properties
 In addition:
 * Efficient container creation
@@ Line 125: / Line 147: @@
 * Support for different storage types
-== See also ==
+== See also == <!--T:29-->
 * [[Ploop]]
 </translate>
 [[Category: Storage]]

← Older revision		Revision as of 18:58, 23 January 2014
Line 126:		Line 126:
	== See also ==		== See also ==
	* [[Ploop]]		* [[Ploop]]
		+
		+	[[Category: Storage]]

← Older revision		Revision as of 10:33, 4 October 2012
Line 104:		Line 104:

	See [http://openvz.livejournal.com/41835.html Effective live migration with ploop write tracker] blog post for more details.		See [http://openvz.livejournal.com/41835.html Effective live migration with ploop write tracker] blog post for more details.
		+
		+	=== Snapshots ===
		+
		+	With ploop, one can instantly create file system snapshots. TODO describe it

	== Benefits ==		== Benefits ==