CT storage backends
Revision as of 13:21, 6 June 2016 by Narcisgarcia (talk | contribs) (→Solidity in front of failures and security)
<translate>
Contents
Comparison tables
Solidity in front of failures and security
Feature | OVZ Ploop | OVZ SimFS (ext4) | LVM (ext4) | ZFS (~simfs) |
---|---|---|---|---|
I/O isolation | Good | Bad: Some bug could be exploited to escape CT and access HN file system [1] [2] | Good | Good |
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 effect | Same FS | ? | ? |
Maturity in O/VZ | Since 2012 | Since ~2005 | Since 1998 | Since 2014 |
Performance and design features
Feature | OVZ Ploop | OVZ SimFS (ext4) | LVM (ext4) | ZFS (~simfs) |
---|---|---|---|---|
Maximum container volume space | 4 TiB [3] | 1 EiB [4] | ? | 256 ZiB |
Wasted space due to architecture | up to 20% | No | up to 20% | ? |
Disk i/o speed | Fast in any case | Very fast with small amount of containers | Fast in any case | Fast in any case |
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 |
Administrator operations
Feature | OVZ Ploop | OVZ SimFS (ext4) | LVM (ext4) | ZFS (~simfs) |
---|---|---|---|---|
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>