Editing CT storage backends

{{stub}}
<translate>

= Comparison table =

<!--T:1-->
{| class="wikitable sortable" style="text-align: center;"
|-
! Feature
! OVZ Ploop
! OVZ SimFS (ext4)
! LVM (ext4)
! ZFS
|-
!colspan="11" style="font-style:bold;background-color:gold;"|1. Solidity in front of failures and security
|-
|'''I/O isolation'''
|{{Yes|Good}}
|{{No|Bad}}: Possibility of "no inodes" issues (when file system journal become a bottleneck).
|{{Yes|Good}}
|{{Yes|Good}}
|-
|'''Security'''
|{{Yes|Good}}
|{{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>
|
|
|-
|'''Reliability'''
|{{No|Low}}: big amount of files produce ext4 corruption so often
|Medium: fsck, power loss and HW Raid without cache can kill whole data
|High: LVM metadata can be corrupted completely
|{{Yes|Excellent}}: no write hole, checksumming and COW
|-
|'''Filesystem over filesystem'''
|Yes
|No
|No
|?
|-
|'''Effect of HN filesystem corruption at /vz'''
|{{Yes|No corruption}}
|{{No|Possible corruption}}
|?
|?
|-
|'''Maturity in O/VZ'''
|{{Yes|Since 2012}}
|{{Yes|Since ~2005}}
|{{Yes|Since 1998}}
|{{Yes|Since 2014}}
|-
!colspan="11" style="font-style:bold;background-color:gold;"|2. Performance and design features
|-
|'''Maximum container volume space'''
|4 TiB <ref>[[Ploop/Limits]]</ref>
|1 EiB <ref>[https://en.wikipedia.org/wiki/Ext4 Ext4]</ref>
|?
|256 ZiB
|-
|'''Disk space overhead'''
|Up to 20%
|No
|Up to 20%
|?
|-
|'''Disk I/O speed'''
|Fast
|Fast only with small amount of containers per node, slowdown in case of big number of small files.
|Fast
|Fast
|-
|'''Disk space overcommit (provide more space for containers than available on server now)'''
|{{Yes}}
|{{Yes}}
|No
|{{Yes}}
|-
|'''Different containers may use file systems of different types and properties'''
|{{Yes}}
|{{No}}
|Yes
|No
|-
|'''Second level quotes in Linux (inside container)'''
|{{Yes}}
|{{Yes}}
|{{Yes}}
|{{No|Not implemented}}
|-
|'''Potential support for QCOW2 and other image formats'''
|{{Yes}}
|{{No}}
|{{No}}
|No
|-
|'''Incremental backup support on filesystem level'''
|{{Yes}}, through snapshots
|{{No}}
|{{No}}
|{{Yes}}
|-
|'''Shared storage support (Virtuozzo storage, NFS)'''
|{{Yes|Yes}}
|{{No|No}}
|{{Yes|Yes}}
|?
|-
!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}}
|?
|?
|-
|'''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|Fast}}
|{{Yes|Fast}} theoretically
|-
|'''Snapshot support'''
|{{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}}
|-
|'''Live migration'''
|{{Yes|Reliable and fast}}
|{{No|Not reliable and slow}}, if some application depends on inode IDs
|{{No|Not implemented}}
|{{Yes|Fast}} theoretically
|-
|'''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>

[[Category: Storage]]