Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
Oh, again, this debate always goes on and on :) Guys, try ZFS yourselves and come back here :) You obviously haven't seen ARC caching in action. You haven't played with snapshots. You haven't seen what the online compression can do. Etc., etc., etc. There's lots to ZFS, which neither BTRFS will ever even remotely approach. Try having this config: - 300+ containers on a single node - 128G RAM - 6 spindles, 2 SSDs - run MySQL on at least 50 of the containers Not only it is way too faster than anything you could do with ext4 even if it's split via ploop into smaller filesystems, it is also much, much easier to manage. ZFS has a tree structure of filesystems with property inheritance. It's designed to be The Solution for situations exactly like this one. The only shortcoming I can really see and mention from my experience of running an OpenVZ based hosting with 850 active CTs on top of ZFS, is that it lacks the support for dquota. I've looked into integrating dquota with ZFS, but it's such an utter mess of an invention, that I have quickly changed my mind and instead we're just doing more datasets (== subvolumes in BTRFS). They are really inexpensive (16kB each), can have own size limits (quotas in ZFS lingo) and thanks to the tree structure with inheritance it's easy to manage them. Also, forget about rsync and all that crap. Send/receive kills it with ease. /snajpa On 11/12/2014 09:48 PM, Scott Dowdle wrote: 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, ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
Greetings, - Original Message - There's lots to ZFS, which neither BTRFS will ever even remotely approach. Not really. That isn't to say that btrfs is done or that all of its features, especially those added much later in the development cycle, are stable. So, I don't contend that btrfs is a suitable contender to zfs at the moment but it does have a few benefits that will eventually put it over the top... past zfs on Linux. What are they? 1) It's in the mainline kernel and will be available in all distros with sufficiently new enough kernels. That's it. That's all it needs. Being part of mainline Linux means that it'll get better integration with system tools by the distros and hopefully OpenVZ at some point. ZoL will never get that... unless of course a Linux distro built just for ZoL comes along. Because of licensing issues, none of the major Linux distros will ever ship with ZoL pre-installed. Sure you can add it yourself... and it does a fairly good job of rebuilding itself when the kernel changes... but the extra work to add it and keep it updated will make it always be adopted less than something that is built-in. Kudos to the ZoL developers for creating such a solid product and making packages for many distros and making it as easy as possible to add. For those not wanting all of the more advanced features btrfs is ready now... and as I stated, SUSE and Oracle have been shipping it for some time. When Red Hat signs off on it, I think that'll raise its status a bit. For those just using it for checksums and CoW, it offers those advantages now. So far as a feature for feature comparison of zfs and btrfs there is probably a 95% feature overlap with btrfs having some features that zfs doesn't and vice versa. Do I blame anyone for using zfs? No. It's great. I just don't want to use it myself. The good thing is that is is very unlikely that Oracle will ever sue over patent issues... because they were the early sponsor of btrfs when most of the work was being done so they only have themselves to blame. 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
Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
Well, innovation isn't about matching features that someone else has just for the sake of having them too, is it? :) What lot of people are missing about ZFS is that it is a self-contained project trying to solve real storage problems. It's not trying to be a filesystem. It is a complete storage solution. It's like you'd take a NetApp and plugged it into your kernel directly. Example features of ZFS that BTRFS will never have due to this fact: - ARC - a smart caching mechanism, with which we're able to deliver almost 100% hitrate almost 100% of the time - something that isn't even remotely imaginable with linux LRU dcache - L2ARC - second level ARC enabling you to cache less used ARC entries onto a SSD - dedicated device for ZIL - synchronous writes are a real pain with any CoW filesystem, ZFS solves this so elegantly that it even beats Ext4 there - you can have your sync writes sent to a fast SSD or a NVRAM device. Thanks to this I don't even notice heavy MySQL instances on our machines, until we run out of CPU power. The disks aren't the show-stopper anymore - NFS, SMB, iSCSI integration - people judging ZFS from the traditional linux kernel perspective don't get why should it be a filesystem's job to do these - like I said, ZFS is not trying to be a filesystem. It's trying to be the last storage solution you'll ever need on your server. Etc. I could go on about this a while :) Regarding the licensing issues. Well. ZFS isn't trying to be the best filesystem for Linux. As far as I can remember, nobody from the ZFS world has ever had any ambitions to get it into Linux. Even if the license would allow merging ZFS in the kernel, the reality of ZFS design as a self-contained solution wouldn't probably be accepted as well in the Linux community as it was in FreeBSD. They're two completely different cultures. As I've already mentioned FreeBSD, here comes the next advantage ZFS has over anything that Linux provides - BTRFS included: you can take your pool today and open it on another platform, be it Linux, FreeBSD or Illumos. Work is being done to ensure these implementations don't drift apart and stay compatible - it is know as the OpenZFS project. Regarding the patent issues, the same essentially goes for BTRFS, the main concern wouldn't be Oracle here, it would be NetApp. They hold enough patents to kick anyone around, doesn't matter if it's OpenZFS or BTRFS. Only with Oracle they seem to be okay, because of Sun's previous dealings with NetApp in this regard. However, these patent concerns doesn't seem to hold any ground, as you can see Nexenta and Joyent both making reasonable enough success to tickle NetApp's nerves (especially Nexenta since they're a direct competitor of NetApp in some market segments), yet nobody is suing them. This is even less of an issue for me as everything I operate is in Europe, where software patents don't apply. Now it looks like I'm actually the one who's on holy crusade for ZFS here :) But it all started off with me being really, really disappointed with Ext4 performance. With ZFS I can get 80-120 heavy LAMP stack containers on a single node, whereas the disks would be long dead with Ext4 before I would even reach a half of that. I've played around with having separate ext4 partitions for every CT (it was before ploop), I've tried Facebook Flashcache to catch the sync writes and offload them onto a SSD, I think I have tried everything I could and not much has really changed since then on the Linux storage scene (2012). There's BTRFS, which to a layman looks like it's almost in feature parity with ZFS, but if you actually try to use it, then WAT comes out of your mouth like every second word. It still needs a lot of work. Whereas ZFS as been in the production for more than 8 years now. And it still is in active development with lots of companies and individuals trying to make it better - they have much better starting point as far as the innovations go, because they act on their own playground and they don't have to deal with politics of such a huge project like Linux kernel is. /snajpa On 11/13/2014 06:24 PM, Scott Dowdle wrote: Not really. That isn't to say that btrfs is done or that all of its features, especially those added much later in the development cycle, are stable. So, I don't contend that btrfs is a suitable contender to zfs at the moment but it does have a few benefits that will eventually put it over the top... past zfs on Linux. What are they? 1) It's in the mainline kernel and will be available in all distros with sufficiently new enough kernels. That's it. That's all it needs. Being part of mainline Linux means that it'll get better integration with system tools by the distros and hopefully OpenVZ at some point. ZoL will never get that... unless of course a Linux distro built just for ZoL comes along. Because of licensing issues, none of the major Linux distros will ever ship with ZoL pre-installed. Sure you
Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
Hello! Pavel! Awesome! Please add one killer feature about ZFS - compete support for SSD with TRIM and not-killing-this-sector-by-thousands-writes :) On Thu, Nov 13, 2014 at 11:17 PM, Pavel Snajdr li...@snajpa.net wrote: Well, innovation isn't about matching features that someone else has just for the sake of having them too, is it? :) What lot of people are missing about ZFS is that it is a self-contained project trying to solve real storage problems. It's not trying to be a filesystem. It is a complete storage solution. It's like you'd take a NetApp and plugged it into your kernel directly. Example features of ZFS that BTRFS will never have due to this fact: - ARC - a smart caching mechanism, with which we're able to deliver almost 100% hitrate almost 100% of the time - something that isn't even remotely imaginable with linux LRU dcache - L2ARC - second level ARC enabling you to cache less used ARC entries onto a SSD - dedicated device for ZIL - synchronous writes are a real pain with any CoW filesystem, ZFS solves this so elegantly that it even beats Ext4 there - you can have your sync writes sent to a fast SSD or a NVRAM device. Thanks to this I don't even notice heavy MySQL instances on our machines, until we run out of CPU power. The disks aren't the show-stopper anymore - NFS, SMB, iSCSI integration - people judging ZFS from the traditional linux kernel perspective don't get why should it be a filesystem's job to do these - like I said, ZFS is not trying to be a filesystem. It's trying to be the last storage solution you'll ever need on your server. Etc. I could go on about this a while :) Regarding the licensing issues. Well. ZFS isn't trying to be the best filesystem for Linux. As far as I can remember, nobody from the ZFS world has ever had any ambitions to get it into Linux. Even if the license would allow merging ZFS in the kernel, the reality of ZFS design as a self-contained solution wouldn't probably be accepted as well in the Linux community as it was in FreeBSD. They're two completely different cultures. As I've already mentioned FreeBSD, here comes the next advantage ZFS has over anything that Linux provides - BTRFS included: you can take your pool today and open it on another platform, be it Linux, FreeBSD or Illumos. Work is being done to ensure these implementations don't drift apart and stay compatible - it is know as the OpenZFS project. Regarding the patent issues, the same essentially goes for BTRFS, the main concern wouldn't be Oracle here, it would be NetApp. They hold enough patents to kick anyone around, doesn't matter if it's OpenZFS or BTRFS. Only with Oracle they seem to be okay, because of Sun's previous dealings with NetApp in this regard. However, these patent concerns doesn't seem to hold any ground, as you can see Nexenta and Joyent both making reasonable enough success to tickle NetApp's nerves (especially Nexenta since they're a direct competitor of NetApp in some market segments), yet nobody is suing them. This is even less of an issue for me as everything I operate is in Europe, where software patents don't apply. Now it looks like I'm actually the one who's on holy crusade for ZFS here :) But it all started off with me being really, really disappointed with Ext4 performance. With ZFS I can get 80-120 heavy LAMP stack containers on a single node, whereas the disks would be long dead with Ext4 before I would even reach a half of that. I've played around with having separate ext4 partitions for every CT (it was before ploop), I've tried Facebook Flashcache to catch the sync writes and offload them onto a SSD, I think I have tried everything I could and not much has really changed since then on the Linux storage scene (2012). There's BTRFS, which to a layman looks like it's almost in feature parity with ZFS, but if you actually try to use it, then WAT comes out of your mouth like every second word. It still needs a lot of work. Whereas ZFS as been in the production for more than 8 years now. And it still is in active development with lots of companies and individuals trying to make it better - they have much better starting point as far as the innovations go, because they act on their own playground and they don't have to deal with politics of such a huge project like Linux kernel is. /snajpa On 11/13/2014 06:24 PM, Scott Dowdle wrote: Not really. That isn't to say that btrfs is done or that all of its features, especially those added much later in the development cycle, are stable. So, I don't contend that btrfs is a suitable contender to zfs at the moment but it does have a few benefits that will eventually put it over the top... past zfs on Linux. What are they? 1) It's in the mainline kernel and will be available in all distros with sufficiently new enough kernels. That's it. That's all it needs. Being part of mainline Linux means that it'll get better
Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
On 11/13/2014 11:20 PM, Kir Kolyshkin wrote: On 11/13/2014 12:52 PM, Pavel Odintsov wrote: Hello! Pavel! Awesome! Please add one killer feature about ZFS - compete support for SSD with TRIM and not-killing-this-sector-by-thousands-writes :) Actually ZoL doesn't support TRIM, neither does Illumos, it's been only implemented in FreeBSD so far. However there's a pull request pending, I guess it will come to merging it to ZoL in coming months, as right now priorities of ZoL developers are mainly on getting some weird memory management issues out of the way. Hmm, aren't all SSD drives have built-in wear leveling? Yes they do. But in order for that wear-leveling to do its job, the drive needs to know which space is not used and the only way to do that is with TRIM/DISCARD - the OS needs to tell the drive where the data is considered to be free space, the drive isn't able to understand all the possible filesystems which can be on it. /snajpa On Thu, Nov 13, 2014 at 11:17 PM, Pavel Snajdr li...@snajpa.net wrote: Well, innovation isn't about matching features that someone else has just for the sake of having them too, is it? :) What lot of people are missing about ZFS is that it is a self-contained project trying to solve real storage problems. It's not trying to be a filesystem. It is a complete storage solution. It's like you'd take a NetApp and plugged it into your kernel directly. Example features of ZFS that BTRFS will never have due to this fact: - ARC - a smart caching mechanism, with which we're able to deliver almost 100% hitrate almost 100% of the time - something that isn't even remotely imaginable with linux LRU dcache - L2ARC - second level ARC enabling you to cache less used ARC entries onto a SSD - dedicated device for ZIL - synchronous writes are a real pain with any CoW filesystem, ZFS solves this so elegantly that it even beats Ext4 there - you can have your sync writes sent to a fast SSD or a NVRAM device. Thanks to this I don't even notice heavy MySQL instances on our machines, until we run out of CPU power. The disks aren't the show-stopper anymore - NFS, SMB, iSCSI integration - people judging ZFS from the traditional linux kernel perspective don't get why should it be a filesystem's job to do these - like I said, ZFS is not trying to be a filesystem. It's trying to be the last storage solution you'll ever need on your server. Etc. I could go on about this a while :) Regarding the licensing issues. Well. ZFS isn't trying to be the best filesystem for Linux. As far as I can remember, nobody from the ZFS world has ever had any ambitions to get it into Linux. Even if the license would allow merging ZFS in the kernel, the reality of ZFS design as a self-contained solution wouldn't probably be accepted as well in the Linux community as it was in FreeBSD. They're two completely different cultures. As I've already mentioned FreeBSD, here comes the next advantage ZFS has over anything that Linux provides - BTRFS included: you can take your pool today and open it on another platform, be it Linux, FreeBSD or Illumos. Work is being done to ensure these implementations don't drift apart and stay compatible - it is know as the OpenZFS project. Regarding the patent issues, the same essentially goes for BTRFS, the main concern wouldn't be Oracle here, it would be NetApp. They hold enough patents to kick anyone around, doesn't matter if it's OpenZFS or BTRFS. Only with Oracle they seem to be okay, because of Sun's previous dealings with NetApp in this regard. However, these patent concerns doesn't seem to hold any ground, as you can see Nexenta and Joyent both making reasonable enough success to tickle NetApp's nerves (especially Nexenta since they're a direct competitor of NetApp in some market segments), yet nobody is suing them. This is even less of an issue for me as everything I operate is in Europe, where software patents don't apply. Now it looks like I'm actually the one who's on holy crusade for ZFS here :) But it all started off with me being really, really disappointed with Ext4 performance. With ZFS I can get 80-120 heavy LAMP stack containers on a single node, whereas the disks would be long dead with Ext4 before I would even reach a half of that. I've played around with having separate ext4 partitions for every CT (it was before ploop), I've tried Facebook Flashcache to catch the sync writes and offload them onto a SSD, I think I have tried everything I could and not much has really changed since then on the Linux storage scene (2012). There's BTRFS, which to a layman looks like it's almost in feature parity with ZFS, but if you actually try to use it, then WAT comes out of your mouth like every second word. It still needs a lot of work. Whereas ZFS as been in the production for more than 8 years now. And it still is in active development with lots of companies and individuals trying to make it
Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
Hello! I created comparison table for answer to your question: https://github.com/pavel-odintsov/OpenVZ_ZFS/blob/master/openvz_storage_backends.md On Wed, Nov 12, 2014 at 7:10 PM, Scott Dowdle dow...@montanalinux.org wrote: Greetings, - Original Message - Tonight I tested and prepared very short and reliable guide about running OpenVZ container on top of best-ever-and-ever-zettabyte-filesystem ZFS. You can find manual here: https://github.com/pavel-odintsov/OpenVZ_ZFS/blob/master/OpenVZ_containers_on_zfs_filesystem.md Any questions/suggestions/performance test and other feedback are welcome here or on GitHub! How well does ploop work? ploop has been the default container filesystem for a while now. 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 -- Sincerely yours, Pavel Odintsov ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
Well, good beginning, but.. as we discussed earlier: in most cases of hosting purposes users need quotes. And quotes work only with ext4. So the only real possible case of usage is ploop over zfs and the only good reason to have zfs here is l2arc cache on ssd or large amount SSD disks in raidz3 over iSCSI... ..and there are still no speed tests. 12.11.2014 15:20, Pavel Odintsov пишет: Any questions/suggestions/performance test and other feedback are welcome here or on GitHub! -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
Thank you for suggestion! Just added! On Wed, Nov 12, 2014 at 9:20 PM, CoolCold coolthec...@gmail.com wrote: I think you should add some links for general zfs-on-linux with openvz install / setup guide, to help people who will be inspired by your readme On Wed, Nov 12, 2014 at 1:20 PM, Pavel Odintsov pavel.odint...@gmail.com wrote: Hello, everyone! Tonight I tested and prepared very short and reliable guide about running OpenVZ container on top of best-ever-and-ever-zettabyte-filesystem ZFS. You can find manual here: https://github.com/pavel-odintsov/OpenVZ_ZFS/blob/master/OpenVZ_containers_on_zfs_filesystem.md Any questions/suggestions/performance test and other feedback are welcome here or on GitHub! Thank you! -- Sincerely yours, Pavel Odintsov ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users -- Best regards, [COOLCOLD-RIPN] ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users -- Sincerely yours, Pavel Odintsov ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
Scott Dowdle mailto:dow...@montanalinux.org Wednesday, November 12, 2014 2:48 PM Greetings, - Original Message - 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. --- I'm assuming ZFS wouldn't have the inode issue if you used the ZFS functions in your migration. If you decided to use ZFS, you should probably use snapshotting, send, and receive during the migration rather than using vzmigrate. ZFS isn't going to be a drop-in replacement if you want to get the most out of it. The problem I have with it is the performance issues. During testing, I have had a lot of random performance issues and write overhead. ZoL (ZFS on Linux) just doesn't seem stable enough yet. Sincerely, Devon ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
When you need quotes and there is only one way to get them... I don't think ploop is about to solve ext4 troubles. I's just solve some troubles (which are common to a lot of file systems). ZFS in this case is more alternative to Parallels Cloud Storage which is closed source and hard to get even for money (I contacted Parallels sales several times and never got the pricelist from them). Also, ZFS is good in case of NAS with large amount of SSDs or usual disks with l2arc cache on SSD. And you can use ploop over ZFS in this case. I suppose ploop over glusterfs (for example) and most of others file system with any redundancy (I mean any realization of raid idea) will be more pain then usable solution, for comparison. 13.11.2014 0:25, Pavel Odintsov пишет: Hello, Nick! 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. On Wed, Nov 12, 2014 at 9:56 PM, Nick Knutov m...@knutov.com wrote: Well, good beginning, but.. as we discussed earlier: in most cases of hosting purposes users need quotes. And quotes work only with ext4. So the only real possible case of usage is ploop over zfs and the only good reason to have zfs here is l2arc cache on ssd or large amount SSD disks in raidz3 over iSCSI... ..and there are still no speed tests. 12.11.2014 15:20, Pavel Odintsov пишет: Any questions/suggestions/performance test and other feedback are welcome here or on GitHub! -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
Parallels Cloud Storage is not an real filesystem in old filesystems terms, it based on ext4 locally and provides only remote features like redundancy and multi level caching. On Wed, Nov 12, 2014 at 11:40 PM, Nick Knutov m...@knutov.com wrote: When you need quotes and there is only one way to get them... I don't think ploop is about to solve ext4 troubles. I's just solve some troubles (which are common to a lot of file systems). ZFS in this case is more alternative to Parallels Cloud Storage which is closed source and hard to get even for money (I contacted Parallels sales several times and never got the pricelist from them). Also, ZFS is good in case of NAS with large amount of SSDs or usual disks with l2arc cache on SSD. And you can use ploop over ZFS in this case. I suppose ploop over glusterfs (for example) and most of others file system with any redundancy (I mean any realization of raid idea) will be more pain then usable solution, for comparison. 13.11.2014 0:25, Pavel Odintsov пишет: Hello, Nick! 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. On Wed, Nov 12, 2014 at 9:56 PM, Nick Knutov m...@knutov.com wrote: Well, good beginning, but.. as we discussed earlier: in most cases of hosting purposes users need quotes. And quotes work only with ext4. So the only real possible case of usage is ploop over zfs and the only good reason to have zfs here is l2arc cache on ssd or large amount SSD disks in raidz3 over iSCSI... ..and there are still no speed tests. 12.11.2014 15:20, Pavel Odintsov пишет: Any questions/suggestions/performance test and other feedback are welcome here or on GitHub! -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users -- Sincerely yours, Pavel Odintsov ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
Nick Knutov mailto:m...@knutov.com Wednesday, November 12, 2014 3:40 PM ZFS in this case is more alternative to Parallels Cloud Storage which is closed source and hard to get even for money (I contacted Parallels sales several times and never got the pricelist from them). Also, ZFS is good in case of NAS with large amount of SSDs or usual disks with l2arc cache on SSD. And you can use ploop over ZFS in this case. I suppose ploop over glusterfs (for example) and most of others file system with any redundancy (I mean any realization of raid idea) will be more pain then usable solution, for comparison. I don't think you can just run ploop over ZFS. Ploop requires ext4 as the host filesystem according to bug 2277: https://bugzilla.openvz.org/show_bug.cgi?id=2277 ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
Re: [Users] Shortest guide about running OpenVZ containers on top of ZFS
Oh. I missed this. 13.11.2014 2:28, Devon B. пишет: I don't think you can just run ploop over ZFS. Ploop requires ext4 as the host filesystem according to bug 2277: https://bugzilla.openvz.org/show_bug.cgi?id=2277 -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 ___ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
