1,433
edits
Changes
Importing a new version from external source
{| class="wikitable sortable" style="text-align: center;"
! Feature
! Ploop
! SIMFS
|-
|'''Maturity'''
|Since 2012
|Since 2005 (?)
|-
|'''Maximum disk space'''
|Limited:<ref>[[Ploop/Limits]]</ref> 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}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref><ref>[[Ploop/Backup]]</ref>, 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 [https://lists.openvz.org/pipermail/users/2015-July/006335.html 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}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref>
|{{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: [https://bugs.openvz.org/browse/OVZ-6296 CVE-2015-2925], [http://www.openwall.com/lists/oss-security/2014/06/24/16 CVE-2014-3519], CVE-2015-6927)
|-
|'''Shared storage support (Virtuozzo storage, NFS)'''
|{{Yes}}
|{{No}}
|-
|''' Disk space footprint'''
|{{Yes}}
|{{No}}
|-
|}
! Feature
! Ploop
! SIMFS
|-
|'''Maturity'''
|Since 2012
|Since 2005 (?)
|-
|'''Maximum disk space'''
|Limited:<ref>[[Ploop/Limits]]</ref> 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}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref><ref>[[Ploop/Backup]]</ref>, 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 [https://lists.openvz.org/pipermail/users/2015-July/006335.html 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}}<ref name="ploop backup">[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref>
|{{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: [https://bugs.openvz.org/browse/OVZ-6296 CVE-2015-2925], [http://www.openwall.com/lists/oss-security/2014/06/24/16 CVE-2014-3519], CVE-2015-6927)
|-
|'''Shared storage support (Virtuozzo storage, NFS)'''
|{{Yes}}
|{{No}}
|-
|''' Disk space footprint'''
|{{Yes}}
|{{No}}
|-
|}
