Editing CT storage backends

Jump to: navigation, search

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:
 
{{stub}}
 
{{stub}}
−
<translate>
 
  
−
= Comparison table =
 
  
−
<!--T:1-->
+
{| class="wikitable sortable"
−
{| class="wikitable sortable" style="text-align: center;"
 
−
|-
 
 
! Feature
 
! Feature
−
! OVZ Ploop
+
! Ploop
−
! OVZ SimFS (ext4)
+
! SIMFS
−
! LVM (ext4)
 
−
! ZFS
 
 
|-
 
|-
−
!colspan="11" style="font-style:bold;background-color:gold;"|1. Solidity in front of failures and security
+
|'''Maturity'''
 +
|Since 2012
 +
|Since 2005 (?)
 
|-
 
|-
−
|'''I/O isolation'''
+
|'''Maximum disk space'''
−
|{{Yes|Good}}
+
|Limited:<ref>[[Ploop/Limits]]</ref> ploop v1 - 2 Tb, ploop v2 - 4 Tb
−
|{{No|Bad}}: Possibility of "no inodes" issues (when file system journal become a bottleneck).
+
|Limited by ext4 filesystem
−
|{{Yes|Good}}
 
−
|{{Yes|Good}}
 
 
|-
 
|-
−
|'''Security'''
+
|'''Disk space overhead'''
−
|{{Yes|Good}}
+
|{{Yes}}, up to 20% for allocated ext4 metadata
−
|{{No|Bad}}: Some bug could be exploited to escape CT and access HN file system <ref>[https://bugs.openvz.org/browse/OVZ-6296 CVE-2015-2925]</ref> <ref>[http://www.openwall.com/lists/oss-security/2014/06/24/16 CVE-2014-3519]</ref>
+
|{{No}}
−
|
 
−
|
 
 
|-
 
|-
−
|'''Reliability'''
+
|'''Speed'''
−
|{{No|Low}}: big amount of files produce ext4 corruption so often
+
|Fast in any case
−
|Medium: fsck, power loss and HW Raid without cache can kill whole data
+
|Very fast with small amount of containers per node
−
|High: LVM metadata can be corrupted completely
 
−
|{{Yes|Excellent}}: no write hole, checksumming and COW
 
 
|-
 
|-
−
|'''Filesystem over filesystem'''
+
|'''I/O isolation'''
−
|Yes
+
|Good
−
|No
+
|Bad, "no inodes" issues (when file system journal is bottleneck)
−
|No
 
−
|{{Yes|Using zvol}}
 
 
|-
 
|-
−
|'''Effect of HN filesystem corruption at /vz'''
+
|'''Need for run external tools for compaction VE images'''
−
|{{Yes|No corruption}}
+
|{{Yes}}, you should vzctl compact every few days for saving your disk space
−
|{{No|Possible corruption}}
+
|{{No}}
−
|?
 
−
|?
 
 
|-
 
|-
−
|'''Maturity in O/VZ'''
+
|'''Disk space overcommit (provide more space for containers than available on server now)'''
−
|{{Yes|Since 2012}}
+
|{{Yes}}
−
|{{Yes|Since ~2005}}
+
|{{Yes}}
−
|{{Yes|Since 1998}}
 
−
|{{Yes|Since 2014}}
 
 
|-
 
|-
−
!colspan="11" style="font-style:bold;background-color:gold;"|2. Performance and design features
+
|'''Reliability'''
 +
|Low: big amount of files produce ext4 corruption so often
 +
|High: fsck, power loss and HW Raid without cache can kill whole data
 
|-
 
|-
−
|'''Maximum container volume space'''
+
|'''Access to private area from host '''
−
|4 TiB <ref>[[Ploop/Limits]]</ref>
+
|{{Yes}}
−
|1 EiB <ref>[https://en.wikipedia.org/wiki/Ext4 Ext4]</ref>
+
|{{Yes}}
−
|?
 
−
|256 ZiB
 
 
|-
 
|-
−
|'''Disk space overhead'''
+
|'''Fear to use filesystem over filesystem'''
−
|Up to 20%
+
|{{Yes}}
−
|No
+
|{{No}}
−
|Up to 20%
 
−
|No, but if using zvol is up to 50% depending on volblocksize
 
 
|-
 
|-
−
|'''Disk I/O speed'''
+
|'''Live backup is easy and consistent'''
−
|Fast
+
|{{Yes}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref>, fast block level backup
−
|Fast only with small amount of containers per node, slowdown in case of big number of small files.
+
|{{No}} (in case of big number of files )
−
|Fast
 
−
|Fast
 
 
|-
 
|-
−
|'''Disk space overcommit (provide more space for containers than available on server now)'''
+
|'''Incremental backup support on filesystem level'''
−
|{{Yes}}
+
|{{Yes}} (snapshots)
−
|{{Yes}}
+
|{{No}}
−
|No
 
−
|{{Yes}}
 
 
|-
 
|-
 
|'''Different containers may use file systems of different types and properties'''
 
|'''Different containers may use file systems of different types and properties'''
 
|{{Yes}}
 
|{{Yes}}
 
|{{No}}
 
|{{No}}
 +
|-
 +
|'''Live migration is reliable and efficient'''
 
|{{Yes}}
 
|{{Yes}}
−
|{{Yes|Using zvol}}
+
|{{No}}, when apps rely on files i-node numbers being constant (which is normally the case), those apps are not surviving the migration
 +
|-
 +
|'''Continue failed CT migration'''
 +
|{{No}}, see also explanation from Kir
 +
|{{Yes}}, option "--keep-dst"
 
|-
 
|-
 
|'''Second level quotes in Linux (inside container)'''
 
|'''Second level quotes in Linux (inside container)'''
 
|{{Yes}}
 
|{{Yes}}
 
|{{Yes}}
 
|{{Yes}}
 +
|-
 +
|'''[Potential] support for QCOW2 and other image formats'''
 
|{{Yes}}
 
|{{Yes}}
−
|{{Yes|Using zvol}}
+
|{{No}}
 
|-
 
|-
−
|'''Potential support for QCOW2 and other image formats'''
+
|'''No problems with fs corruption on /vz parition'''
 
|{{Yes}}
 
|{{Yes}}
 
|{{No}}
 
|{{No}}
−
|{{No}}
 
−
|{{No}}
 
 
|-
 
|-
−
|'''Incremental backup support on filesystem level'''
+
|'''Snapshot support'''
−
|{{Yes}}, through snapshots
+
|{{Yes}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref>
−
|{{No}}
+
|{{No}}, (because there is a lot of small files that need to be copied)
−
|{{No}}
+
|-
 +
|'''Better security'''
 
|{{Yes}}
 
|{{Yes}}
 +
|{{No}} (bugs can be exploited to escape the simfs and let container access the host file system: [https://bugs.openvz.org/browse/OVZ-6296 CVE-2015-2925], [http://www.openwall.com/lists/oss-security/2014/06/24/16 CVE-2014-3519], CVE-2015-6927)
 
|-
 
|-
 
|'''Shared storage support (Virtuozzo storage, NFS)'''
 
|'''Shared storage support (Virtuozzo storage, NFS)'''
−
|{{Yes|Yes}}
 
−
|{{No|No}}
 
−
|{{Yes|Yes}}
 
−
|{{Yes|NFS only}}
 
−
|-
 
−
!colspan="11" style="font-style:bold;background-color:gold;"|3. Maintenance
 
−
|-
 
−
|'''vzctl integration'''
 
−
|{{Yes|Complete}}
 
−
|{{Yes|Complete}}
 
−
|{{No}}, many manual operations
 
−
|{{No}}, some manual operations
 
−
|-
 
−
|'''External compaction for container volumes'''
 
−
|{{No|Needed}} for saving HN space
 
−
|{{Yes|No}}
 
−
|{{No|Not available}}
 
−
|{{Yes|Not required}}
 
−
|-
 
−
|'''Access to private area from host'''
 
 
|{{Yes}}
 
|{{Yes}}
−
|{{Yes}}
+
|{{No}}
−
|?
 
−
|{{Yes|Only using ZFS filesystem}}
 
−
|-
 
−
|'''Live backup'''
 
−
|{{Yes|Easy, fast and consistent}}<ref>[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref> <ref>[[Ploop/Backup]]</ref>
 
−
|{{No|Easy, slow, and sometimes inconsistent}} in case some application depends on inode IDs
 
−
|{{No|No}}
 
−
|{{Yes|Fast}} via ZFS Send/Receive
 
 
|-
 
|-
−
|'''Snapshot support'''
+
|''' Disk space footprint'''
−
|{{Yes}}<ref>[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref>
 
−
|{{No}} theoretically, because of much/small files to be copied
 
−
|{{Yes}}
 
 
|{{Yes}}
 
|{{Yes}}
 +
|{{No}}
 
|-
 
|-
−
|'''Live migration'''
+
}
−
|{{Yes|Reliable and fast}}
+
 
−
|{{No|Not reliable and slow}}, if some application depends on inode IDs
 
−
|{{No|Not implemented}}
 
−
|{{Yes|Fast}} via ZFS Send/Receive
 
−
|-
 
−
|'''Continue failed CT migration'''
 
−
|{{Yes}}, in [https://lists.openvz.org/pipermail/users/2015-July/006335.html vzctl] from OpenVZ -stable
 
−
|{{Yes}}, option "--keep-dst"
 
−
|{{No|Not implemented}}
 
−
|?
 
−
|-
 
−
|}
 
  
−
</translate>
+
* [[Ploop]]
  
 
[[Category: Storage]]
 
[[Category: Storage]]

Please note that all contributions to OpenVZ Virtuozzo Containers Wiki may be edited, altered, or removed by other contributors. If you don't want your writing to be edited mercilessly, then don't submit it here.
 If you are going to add external links to an article, read the External links policy first!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)

Templates used on this page:

Retrieved from "https://wiki.openvz.org/CT_storage_backends"