On 07/21/2015 08:51 AM, Michael Stauber wrote:
Hi Scott,
Ummm, you can still access the files inside of ploop-based container
when it isn't running... simply by mounting it. Is there an issue
with that?
Granted: It's probably more of a psychological or philosophical issue
than a technical one. Filesystem on a filesystem. That adds a level of
complexity and another potential point of failure. Yes, it has benefits.
But ease of access to anything while using simfs often seems to
outweight that. Even if people don't use it for that reason: It adds
some peace of mind that they could - if they wanted to. Potential quota
and inode issues alone won't deter them from using simfs that way.
The biggest problem with simfs appears to be security. We have recently
found a few bugs (not in simfs per se, but in the kernel in general,
i.e. these
are not our bugs for the most part) that can be exploited to escape
the simfs and let container access the host file system. 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 :(
Other "why not simfs" considerations are listed at
http://openvz.org/Ploop/Why#Before_ploop
Of those, the biggest issue is common filesystem journal. A single
container can issue a lot
of operations (like file truncate) leading to lots of journal updates,
essentially blocking the rest
of containers to do anything what involves journal. This is bad as it
breaks inter-container
isolation to some degree.
Think of existing architectures where someone fiddled in some custom
backup scripts to do partial or complete VPS backups.
Well, this is just plain wrong wrong. The correct way to access a VPS
filesystem (doesn't matter
if this is ploop or simfs or something else) is:
vzctl mount $CTID
cd /vz/root/$CTID # to prevent unmount say if a container is stopped
# work with data at /vz/root/$CTID
vzctl umount $CTID
Sure, it's
possible with ploop, too. But it would require tampering with something
that ain't broken to begin with.
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.
You would argue that accessing /vz/private/$CTID read-only is OK from
the perspective
of vzquota -- I'd say it is just a wrong assumption that a container
files can be accessed
from /vz/private/$CTID -- it just happens to work with current simfs and
OpenVZ.
Don't get me wrong: I like ploop and have no issue with it. Other
virtualization solutions (containerized or not) also usually have their
own filesystem for VMs or containers and direct access to that from the
HN also needs some crutches or work arounds. Still: I'd be fighting an
uphill battle if I'd were to introduce it as default for my users.
Somehow ploop doesn't provide a "killer-feature" that would help me in
convincing those that either don't know ploop yet, or haven't used it
yet. But maybe someone has some talking points that would help me to win
some hearts and minds there?
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.
To get back to the original question that Sergey asked: He maybe asked
because they're considering to eventually drop simfs support. Because
that's how I'd test the waters if I were to retire some legacy features
from my own projects. To that I humbly say: Please don't. We like that
ugly duckling and would like to keep it. Alternatively: Give us a really
good reason (or a "killer-feature") that makes it a "must have" item.
_______________________________________________
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
