[Devel] [PATCH rh7] fs: make overlayfs disabled in CT by default
Maxim Patlasov
mpatlasov at virtuozzo.com
Tue Jul 5 16:45:10 PDT 2016
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
More information about the Devel
mailing list