CT storage backends
<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>