Vova,
On 07/04/2016 11:03 AM, Maxim Patlasov wrote:
On 07/04/2016 08:53 AM, Vladimir Davydov wrote:
On Tue, Jun 28, 2016 at 03:48:54PM -0700, Maxim Patlasov wrote:
...
@@ -643,6 +643,7 @@ static struct cgroup_subsys_state
*ve_create(struct cgroup *cg)
ve->odirect_enable = 2;
ve->fsync_enable = 2;
+ ve->experimental_fs_enable = 2;
For odirect_enable and fsync_enable, 2 means follow the host's config, 1
means enable unconditionally, and 0 means disable unconditionally. But
we don't want to allow a user inside a CT to enable this feature, right?
I thought it's OK to allow user inside CT to enable it if host
sysadmin is OK about it. The same logic as for odirect: by default
ve0->experimental_fs_enable = 0, so whatever user inside CT writes to
this knob, the feature is disabled. If sysadmin writes '1' to
ve0->..., the feature becomes enabled. If an user wants to voluntarily
disable it inside CT, that's OK too.
This is confusing. May be, we'd better add a new VE_FEATURE for the
purpose?
Not sure right now. I'll look at it and let you know later.
Technically, it is very easy to implement new VE_FEATURE for overlayfs.
But this approach is less flexible because we return EPERM from
ve_write_64 if CT is running, and we'll need to involve userspace team
to make the feature configurable and (possibly) persistent. Do you think
it's worthy for something we'll get rid of soon anyway (I mean as soon
as PSBM-47981 resolved)?
Thanks,
Maxim
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
