Difference between revisions of "CT storage backends"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(Reorganization, deduplication, +LVM +ZFS)
(References, vzctl integration)
Line 3: Line 3:
 
= Comparison tables =
 
= Comparison tables =
  
 +
<!--T:1-->
 
=== Solidity in front of failures and security ===
 
=== Solidity in front of failures and security ===
<!--T:1-->
 
 
{| class="wikitable sortable" style="text-align: center;"
 
{| class="wikitable sortable" style="text-align: center;"
 
! Feature
 
! Feature
Line 14: Line 14:
 
|'''I/O isolation'''
 
|'''I/O isolation'''
 
|{{Yes|Good}}
 
|{{Yes|Good}}
|{{No|Bad}}: Some bug could be exploited to escape CT and access HN 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]
+
|{{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>
 
|{{Yes|Good}}
 
|{{Yes|Good}}
 
|{{Yes|Good}}
 
|{{Yes|Good}}
Line 41: Line 41:
 
|{{Yes|Since 1998}}
 
|{{Yes|Since 1998}}
 
|{{No|Since 2014}}
 
|{{No|Since 2014}}
|-
 
|'''Incremental backup support on filesystem level'''
 
|{{Yes}}, through snapshots
 
|{{No}}
 
|{{No}}
 
|{{Yes}}
 
 
|-
 
|-
 
|}
 
|}
  
 
=== Performance and design features ===
 
=== Performance and design features ===
<!--T:1-->
 
 
{| class="wikitable sortable" style="text-align: center;"
 
{| class="wikitable sortable" style="text-align: center;"
 
! Feature
 
! Feature
Line 61: Line 54:
 
|'''Maximum container volume space'''
 
|'''Maximum container volume space'''
 
|4 TiB <ref>[[Ploop/Limits]]</ref>
 
|4 TiB <ref>[[Ploop/Limits]]</ref>
|1 EiB
+
|1 EiB <ref>[https://en.wikipedia.org/wiki/Ext4 Ext4]</ref>
|1 EiB
+
|?
 
|256 ZiB
 
|256 ZiB
 
|-
 
|-
Line 100: Line 93:
 
|{{No}}
 
|{{No}}
 
|No
 
|No
 +
|-
 +
|'''Incremental backup support on filesystem level'''
 +
|{{Yes}}, through snapshots
 +
|{{No}}
 +
|{{No}}
 +
|{{Yes}}
 
|-
 
|-
 
|}
 
|}
  
 
=== Administrator operations ===
 
=== Administrator operations ===
<!--T:1-->
 
 
{| class="wikitable sortable" style="text-align: center;"
 
{| class="wikitable sortable" style="text-align: center;"
 
! Feature
 
! Feature
Line 111: Line 109:
 
! LVM (ext4)
 
! LVM (ext4)
 
! ZFS (~simfs)
 
! ZFS (~simfs)
 +
|-
 +
|'''vzctl integration'''
 +
|{{Yes|Complete}}
 +
|{{Yes|Complete}}
 +
|{{No|No}}, many manual operations
 +
|{{Yes|No}}, some manual operations
 
|-
 
|-
 
|'''External compaction for container volumes'''
 
|'''External compaction for container volumes'''
Line 125: Line 129:
 
|-
 
|-
 
|'''Live backup'''
 
|'''Live backup'''
|{{Yes|Easy, fast and consistent}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref><ref>[[Ploop/Backup]]</ref>
+
|{{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|Easy, slow, and sometimes inconsistent}} in case some application depends on inode IDs
 
|{{No|Fast}}
 
|{{No|Fast}}
Line 131: Line 135:
 
|-
 
|-
 
|'''Snapshot support'''
 
|'''Snapshot support'''
|{{Yes}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref>
+
|{{Yes}}<ref>[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref>
 
|{{No}} theoretically, because of much/small files to be copied
 
|{{No}} theoretically, because of much/small files to be copied
 
|{{Yes}}
 
|{{Yes}}

Revision as of 13:16, 6 June 2016

<translate>

Comparison tables

Solidity in front of failures and security

Feature OVZ Ploop OVZ SimFS (ext4) LVM (ext4) ZFS (~simfs)
I/O isolation Good Bad: Some bug could be exploited to escape CT and access HN file system [1] [2] Good Good
Reliability 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 Excellent: no write hole, checksumming and COW
Risk to be using filesystem over filesystem Yes No No ?
Effect of HN filesystem corruption at /vz No effect Same FS ? ?
Maturity in O/VZ Since 2012 Since ~2005 Since 1998 Since 2014

Performance and design features

Feature OVZ Ploop OVZ SimFS (ext4) LVM (ext4) ZFS (~simfs)
Maximum container volume space 4 TiB [3] 1 EiB [4] ? 256 ZiB
Wasted space due to architecture up to 20% No up to 20% ?
Disk i/o speed Fast in any case Very fast with small amount of containers Fast in any case Fast in any case
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 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

Administrator operations

Feature OVZ Ploop OVZ SimFS (ext4) LVM (ext4) ZFS (~simfs)
vzctl integration Complete Complete No, many manual operations No, some manual operations
External compaction for container volumes Needed for saving HN space No Not available Not required
Access to private area from host Yes Yes ? ?
Live backup Easy, fast and consistent[5] [6] Easy, slow, and sometimes inconsistent in case some application depends on inode IDs Fast Fast theoretically
Snapshot support Yes[7] No theoretically, because of much/small files to be copied Yes Yes
Live migration Reliable and fast Not reliable and slow, if some application depends on inode IDs Not implemented Fast theoretically
Continue failed CT migration Yes, in vzctl from OpenVZ -stable Yes, option "--keep-dst" Not implemented ?

</translate>