CT storage backends

Feature	Ploop	SIMFS
Maturity	Since 2012	Since 2005 (?)
Maximum disk space	Limited: 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 in any case	Very fast 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, 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	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