Difference between revisions of "CT storage backends"
(Some ZFS fixes and updates) |
|||
| Line 37: | Line 37: | ||
|No | |No | ||
|No | |No | ||
| − | | | + | |{{Yes|Using zvol}} |
|- | |- | ||
|'''Effect of HN filesystem corruption at /vz''' | |'''Effect of HN filesystem corruption at /vz''' | ||
| Line 63: | Line 63: | ||
|No | |No | ||
|Up to 20% | |Up to 20% | ||
| − | | | + | |No, but if using zvol is up to 50% depending on volblocksize |
|- | |- | ||
|'''Disk I/O speed''' | |'''Disk I/O speed''' | ||
| Line 80: | Line 80: | ||
|{{Yes}} | |{{Yes}} | ||
|{{No}} | |{{No}} | ||
| − | |Yes | + | |{{Yes}} |
| − | | | + | |{{Yes|Using zvol}} |
|- | |- | ||
|'''Second level quotes in Linux (inside container)''' | |'''Second level quotes in Linux (inside container)''' | ||
| Line 87: | Line 87: | ||
|{{Yes}} | |{{Yes}} | ||
|{{Yes}} | |{{Yes}} | ||
| − | |{{ | + | |{{Yes|Using zvol}} |
|- | |- | ||
|'''Potential support for QCOW2 and other image formats''' | |'''Potential support for QCOW2 and other image formats''' | ||
| Line 93: | Line 93: | ||
|{{No}} | |{{No}} | ||
|{{No}} | |{{No}} | ||
| − | |No | + | |{{No}} |
|- | |- | ||
|'''Incremental backup support on filesystem level''' | |'''Incremental backup support on filesystem level''' | ||
| Line 105: | Line 105: | ||
|{{No|No}} | |{{No|No}} | ||
|{{Yes|Yes}} | |{{Yes|Yes}} | ||
| − | | | + | |{{Yes|NFS only}} |
|- | |- | ||
!colspan="11" style="font-style:bold;background-color:gold;"|3. Maintenance | !colspan="11" style="font-style:bold;background-color:gold;"|3. Maintenance | ||
| Line 125: | Line 125: | ||
|{{Yes}} | |{{Yes}} | ||
|? | |? | ||
| − | | | + | |{{Yes|Only using ZFS filesystem}} |
|- | |- | ||
|'''Live backup''' | |'''Live backup''' | ||
|{{Yes|Easy, fast and consistent}}<ref>[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref> <ref>[[Ploop/Backup]]</ref> | |{{Yes|Easy, fast and consistent}}<ref>[http://openvz.livejournal.com/44508.html ploop snapshots and backups]</ref> <ref>[[Ploop/Backup]]</ref> | ||
|{{No|Easy, slow, and sometimes inconsistent}} in case some application depends on inode IDs | |{{No|Easy, slow, and sometimes inconsistent}} in case some application depends on inode IDs | ||
| − | |{{No| | + | |{{No|No}} |
| − | |{{Yes|Fast}} | + | |{{Yes|Fast}} via ZFS Send/Receive |
|- | |- | ||
|'''Snapshot support''' | |'''Snapshot support''' | ||
| Line 143: | Line 143: | ||
|{{No|Not reliable and slow}}, if some application depends on inode IDs | |{{No|Not reliable and slow}}, if some application depends on inode IDs | ||
|{{No|Not implemented}} | |{{No|Not implemented}} | ||
| − | |{{Yes|Fast}} | + | |{{Yes|Fast}} via ZFS Send/Receive |
|- | |- | ||
|'''Continue failed CT migration''' | |'''Continue failed CT migration''' | ||
Latest revision as of 18:02, 15 December 2022
This article is a stub. You can help OpenVZ Wiki by expanding it. <translate>
Comparison table[edit]
| Feature | OVZ Ploop | OVZ SimFS (ext4) | LVM (ext4) | ZFS | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 1. Solidity in front of failures and security | ||||||||||
| I/O isolation | Good | Bad: Possibility of "no inodes" issues (when file system journal become a bottleneck). | Good | Good | ||||||
| Security | Good | Bad: Some bug could be exploited to escape CT and access HN file system [1] [2] | ||||||||
| 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 | Using zvol | ||||||
| Effect of HN filesystem corruption at /vz | No corruption | Possible corruption | ? | ? | ||||||
| Maturity in O/VZ | Since 2012 | Since ~2005 | Since 1998 | Since 2014 | ||||||
| 2. Performance and design features | ||||||||||
| Maximum container volume space | 4 TiB [3] | 1 EiB [4] | ? | 256 ZiB | ||||||
| Disk space overhead | Up to 20% | No | Up to 20% | No, but if using zvol is up to 50% depending on volblocksize | ||||||
| Disk I/O speed | Fast | Fast only with small amount of containers per node, slowdown in case of big number of small files. | Fast | Fast | ||||||
| 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 | Using zvol | ||||||
| Second level quotes in Linux (inside container) | Yes | Yes | Yes | Using zvol | ||||||
| Potential support for QCOW2 and other image formats | Yes | No | No | No | ||||||
| Incremental backup support on filesystem level | Yes, through snapshots | No | No | Yes | ||||||
| Shared storage support (Virtuozzo storage, NFS) | Yes | No | Yes | NFS only | ||||||
| 3. Maintenance | ||||||||||
| 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 | ? | Only using ZFS filesystem | ||||||
| Live backup | Easy, fast and consistent[5] [6] | Easy, slow, and sometimes inconsistent in case some application depends on inode IDs | No | Fast via ZFS Send/Receive | ||||||
| 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 via ZFS Send/Receive | ||||||
| Continue failed CT migration | Yes, in vzctl from OpenVZ -stable | Yes, option "--keep-dst" | Not implemented | ? | ||||||
</translate>
