Greetings, ----- Original Message ----- > Ploop is really useless for ZFS because it solves ext4 troubles and > ZFS haven't this issues by design. Quotes maybe problems, good > addition. I just added remark about quotes to comparison table.
Performance issues aren't the only problem ploop solves... it also solves the changing inode issue. When a container is migrated from one host to another with simfs, inodes will change... and some services don't like that. Also because the size of a ploop disk image is fixed (although changeable), the fixed size acts as a quota... so you get your quota back if you turned it off. For me, unless something changes, ZFS isn't a starter because almost no one ships with it because of licensing issues. How about btrfs? I don't think btrfs is available easily in the existing OpenVZ kernels... nor in a modular format (like ZFS) so we might have to wait until the availability of a RHEL7-based OpenVZ branch. Red Hat still considers btrfs experimental but that may change with upcoming RHEL7 updates. Both SUSE and Oracle have been using btrfs for some time although they do not support btrfs' entire feature set... they stick with the basic features and avoid the less mature ones. Luckily that includes mirror, checksums, snapshoting, subvolumes, etc. I wouldn't put simfs and ploop in the same column as the underlying filesystems. I'm not sure why the chart says that simfs has issues with migration. Other than the inode issue, which isn't an issue with the services I run, simfs actually migrates faster because it doesn't have to transfer the entire disk image... and if the host has been migrated before and has a previous copy of its filesystem available, only the changed files have to be transferred... saving a lot of time. TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
