CT storage backends

From OpenVZ Virtuozzo Containers Wiki
Revision as of 23:25, 25 December 2015 by Sergey Bronnikov (talk | contribs) (add 'translate' tags)
Jump to: navigation, search

<translate>

Feature Ploop SIMFS
Maturity Since 2012 Since 2005 (?)
Maximum disk space Limited:[1] ploop v1 - 2 Tb, ploop v2 - 4 Tb Limited by ext4 filesystem
Disk space overhead Yes, up to 20% for allocated ext4 metadata No
Speed Fast Fast only with small amount of containers per node
I/O isolation Good Bad, "no inodes" issues (when file system journal is bottleneck)
Need for run external tools for compaction VE images Yes, you should vzctl compact every few days for saving your disk space No
Disk space overcommit (provide more space for containers than available on server now) Yes Yes
Reliability Low: big amount of files produce ext4 corruption so often High: fsck, power loss and HW Raid without cache can kill whole data
Access to private area from host Yes Yes
Fear to use filesystem over filesystem Yes No
Live backup is easy and consistent Yes[2][3], fast block level backup No (in case of big number of files )
Incremental backup support on filesystem level Yes (snapshots) No
Different containers may use file systems of different types and properties Yes No
Live migration is reliable and efficient Yes 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 Yes, in vzctl from OpenVZ -stable Yes, option "--keep-dst"
Second level quotes in Linux (inside container) Yes Yes
[Potential] support for QCOW2 and other image formats Yes No
No problems with fs corruption on /vz parition Yes No
Snapshot support Yes[2] No, (because there is a lot of small files that need to be copied)
Better security Yes No (bugs can be exploited to escape the simfs and let container access the host file system: CVE-2015-2925, CVE-2014-3519, CVE-2015-6927)
Shared storage support (Virtuozzo storage, NFS) Yes No
Disk space footprint Yes No

</translate>