Open main menu

OpenVZ Virtuozzo Containers Wiki β

CT storage backends

Revision as of 11:09, 7 June 2016 by Sergey Bronnikov (talk | contribs) (return back row with 'Shared storage support', merge three tables to single table)

<translate>

Comparison table

Feature OVZ Ploop OVZ SimFS (ext4) LVM (ext4) ZFS
1. Solidity in front of failures and security
I/O isolation Good Bad: Possibility of "no inodes" issues (when file system journal become a bottleneck). Good Good
Security Good Bad: Some bug could be exploited to escape CT and access HN file system [1] [2]
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
Filesystem over filesystem Yes No No ?
Effect of HN filesystem corruption at /vz No corruption Possible corruption ? ?
Maturity in O/VZ Since 2012 Since ~2005 Since 1998 Since 2014
2. Performance and design features
Maximum container volume space 4 TiB [3] 1 EiB [4] ? 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 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 No Yes ?
3. Maintenance
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>