Hi Kir, > The biggest problem with simfs appears to be security. [...] One > single bug like that should have everyone who is at least slightly > concerned about security to move to ploop. And there were a few :(
Many thanks for sharing that insight. It's much appreciated. Yeah, this is of course a very valid concern. > I would say it is broken even for simfs. For example, if you change > something in /vz/private/$CTID, such as add, delete, or modify any > files, these changes will not be reflected in vzquota, leading > to wrong disk space usage, and the limits won't work as they should. Indeed. This is something we see frequently and managed to educate our users how to fix it. Like dropping quota, letting it rebuild and then run a script inside the container (which we provide with our tailored OS) to fix the 2nd level quota. It's a bit of a nuisance, but not a crippling one. > http://openvz.org/Ploop/Why > > In addition to everything I said earlier, worth noting are ploop snapshots > (and easy consistent backups!), NFS support, and efficient live migration > using ploop copy. These are all valid points and I thank you for pointing them out. Still: It lacks the "killer-feature" that would prompt people to gladly make the transition from simfs to ploop. As a developer myself I embrace change as it provides new features and things that I can hone my skill on. But the typical end user might be a bit more resistant to change. They need a good and compelling reason to "jump ship" while they're still under steam and sailing smoothly. Security can be such a compelling reason. Snapshotting? It's *really* nice to have. But it doesn't make them bite on its own. Let me give you an example without going to deep into boring details: We recently transitioned our main "product" (an open source hosting solution with GUI) from CentOS5 and CentOS6 to CentOS7. Most of our userbase is now leaving CentOS5 and moving onwards to CentOS 7. Those that now start to use it in an OpenVZ VPS (under Proxmox, native OpenVZ or our own OpenVZ based platform) tend to use simfs, too. Even if it might just for historic reasons or because Ploop isn't supported in the VPS management GUI's yet. These freshly migrated VPS's will be around for quite some time. At least until RHEL8 and it's open source clones come around. These typical hosting VPS's are often used from start to finish of the CentOS life-cycle. Even if the nodes they run on are changed more frequently than that: vzmigrate make it very easy to take the existing VPS's along. Likewise: All the CentOS6 VPS's that our users currently have use simfs. These also most likely be with us until their users get a compelling reason to move onwards. Half of those probably skip CentOS7 and wait for CentOS8. Wouldn't surprise me the least. Should support for simfs eventually be dropped in the near future, then this will create a transitional gap that's a bit difficult to bridge. Of course: Most of us on the list here certainly have a good idea how to best do this and we're all able to bridge that gap one way or the other. But some of our less technically inclined end users might just vote with their feet instead - or they stay on the old platforms that still support simfs. Maybe it's worth the thought to provide vzmigrate with an extension that allows to vzmigrate from a simfs source VPS to ploop target VPS? I can do that "on foot" (if need be) or hack some scripts together that do the transition with or without a migration. But these are things that "rock the boat" and might upset some of our users. Just some food of thought. In any case: Many thanks for your excellent work, which is really much appreciated. -- With best regards Michael Stauber _______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users