[Users] SIMFS users

[Kir Kolyshkin]

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.
>