Question for remount

Question for remount

[KAMEZAWA Hiroyuki]

Followings are 3 stories of remount cgroup,

1. remount with devices.

 # mount -t cgroup none /cgroups -ocpuacct,release_agent=xxx
 # echo > /cgroups/release_agent #clear release agent by hand
 # mount -t cgroup none /cgroups -oremount,cpuacct
 # cat /cgroups/release_agent
   => release_agent is ""

2. remount without devices, mount command will read /proc/mounts and
   copies option.

 # mount -t cgroup none /cgroups -ocpuacct,release_agent=xxx
 # echo > /cgroups/release_agent      #clear release agent by hand
 # mount /cgroups -oremount,cpuacct   #don't specify device
 # cat /cgroups/release_agent
   => xxx

Hmm, release_agent is copied from /proc/mounts and release_agent revives.

3. remount without devices, mount command will read /proc/mounts
 # mount -t cgroup none /cgroups -ocpuacct,release_agent=xxx
 # mount /cgroups -oremount,cpuacct,release_agent=xxx
 => error
 "release_agent=" will be found twice and this returns -INVAL

maybe case "2" is not ideal, I think. (but it may not be bug.)

My point is following.

1. Documentation/cgroups/cgroup.txt says
   #mount -oremount,cpuset,ns /dev/cgroup
   But this should be
   #mount -tcgroup none /dev/cgroup -oremount,cpuset,ns

2. /proc/mounts information of release_agent should be updated....
   when it's overwritten directly.

3. If "2" is impossible, changing release_agent at remount should not be allowed.

How do you think ?

Thanks,
-Kame

Re: Question for remount

[Paul Menage]

On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> 2. /proc/mounts information of release_agent should be updated....
>   when it's overwritten directly.

Yes, definitely. But shouldn't that happen already?
cgroup_show_options() reports the current value of
root->release_agent_path in /proc/mounts. Is it possible that mount is
actually storing/retrieving this information in /etc/mtab, which
doesn't get updated?

Paul

Re: Question for remount

[KAMEZAWA Hiroyuki]

Paul Menage さんは書きました：
> On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>>
>> 2. /proc/mounts information of release_agent should be updated....
>>   when it's overwritten directly.
>
> Yes, definitely. But shouldn't that happen already?
> cgroup_show_options() reports the current value of
> root->release_agent_path in /proc/mounts. Is it possible that mount is
> actually storing/retrieving this information in /etc/mtab, which
> doesn't get updated?
>
Ah, you're right. /proc/mounts is updated but /etc/mtab is not updated.
Hmm..from man mount(1), /etc/mtab is not synchronized with /proc/mounts.
Do we need to allow release_agent override at remount ?

-Kame

Re: Question for remount

[Li Zefan]

KAMEZAWA Hiroyuki wrote:
> Paul Menage さんは書きました：
>> On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki
>> <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> wrote:
>>> 2. /proc/mounts information of release_agent should be updated....
>>>   when it's overwritten directly.
>> Yes, definitely. But shouldn't that happen already?
>> cgroup_show_options() reports the current value of
>> root->release_agent_path in /proc/mounts. Is it possible that mount is
>> actually storing/retrieving this information in /etc/mtab, which
>> doesn't get updated?
>>
> Ah, you're right. /proc/mounts is updated but /etc/mtab is not updated.
> Hmm..from man mount(1), /etc/mtab is not synchronized with /proc/mounts.
> Do we need to allow release_agent override at remount ?
> 

Since we've allowed this behavior, I think we shouldn't disallow it to
supprise users?

Re: Question for remount

[Li Zefan]

KAMEZAWA Hiroyuki wrote:
> Paul Menage さんは書きました：
>> On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki
>> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>>> 2. /proc/mounts information of release_agent should be updated....
>>>   when it's overwritten directly.
>> Yes, definitely. But shouldn't that happen already?
>> cgroup_show_options() reports the current value of
>> root->release_agent_path in /proc/mounts. Is it possible that mount is
>> actually storing/retrieving this information in /etc/mtab, which
>> doesn't get updated?
>>
> Ah, you're right. /proc/mounts is updated but /etc/mtab is not updated.
> Hmm..from man mount(1), /etc/mtab is not synchronized with /proc/mounts.
> Do we need to allow release_agent override at remount ?
> 

Since we've allowed this behavior, I think we shouldn't disallow it to
supprise users?

Re: Question for remount

[KAMEZAWA Hiroyuki]

On Mon, 23 Feb 2009 10:32:46 +0800
Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> wrote:

> KAMEZAWA Hiroyuki wrote:
> > Paul Menage さんは書きました：
> >> On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki
> >> <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> wrote:
> >>> 2. /proc/mounts information of release_agent should be updated....
> >>>   when it's overwritten directly.
> >> Yes, definitely. But shouldn't that happen already?
> >> cgroup_show_options() reports the current value of
> >> root->release_agent_path in /proc/mounts. Is it possible that mount is
> >> actually storing/retrieving this information in /etc/mtab, which
> >> doesn't get updated?
> >>
> > Ah, you're right. /proc/mounts is updated but /etc/mtab is not updated.
> > Hmm..from man mount(1), /etc/mtab is not synchronized with /proc/mounts.
> > Do we need to allow release_agent override at remount ?
> > 
> 
> Since we've allowed this behavior, I think we shouldn't disallow it to
> supprise users?
> 
In a bit different stroy, it already surprises a user (me).
for example)

#mount -t cgroup none /cgroups -ocpu,release_agent=hogehoge
#mount -oremount,cpuacct /cgroups,release_agent=xxxx
=> remount fails. because the option "release_agent" appears twice.

#mount -t cgroup none /cgroups -ocpu,release_agent=hogehoge
#mount -t cgroup none /cgroups -oremount,cpuacct /cgroups,release_agent=xxxx
=> remount success.

At least, updating documentation to notice this is necessary I think.


-Kame

Re: Question for remount

[KAMEZAWA Hiroyuki]

On Mon, 23 Feb 2009 10:32:46 +0800
Li Zefan <lizf@cn.fujitsu.com> wrote:

> KAMEZAWA Hiroyuki wrote:
> > Paul Menage さんは書きました：
> >> On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki
> >> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> >>> 2. /proc/mounts information of release_agent should be updated....
> >>>   when it's overwritten directly.
> >> Yes, definitely. But shouldn't that happen already?
> >> cgroup_show_options() reports the current value of
> >> root->release_agent_path in /proc/mounts. Is it possible that mount is
> >> actually storing/retrieving this information in /etc/mtab, which
> >> doesn't get updated?
> >>
> > Ah, you're right. /proc/mounts is updated but /etc/mtab is not updated.
> > Hmm..from man mount(1), /etc/mtab is not synchronized with /proc/mounts.
> > Do we need to allow release_agent override at remount ?
> > 
> 
> Since we've allowed this behavior, I think we shouldn't disallow it to
> supprise users?
> 
In a bit different stroy, it already surprises a user (me).
for example)

#mount -t cgroup none /cgroups -ocpu,release_agent=hogehoge
#mount -oremount,cpuacct /cgroups,release_agent=xxxx
=> remount fails. because the option "release_agent" appears twice.

#mount -t cgroup none /cgroups -ocpu,release_agent=hogehoge
#mount -t cgroup none /cgroups -oremount,cpuacct /cgroups,release_agent=xxxx
=> remount success.

At least, updating documentation to notice this is necessary I think.


-Kame

Re: Question for remount

[Li Zefan]

KAMEZAWA Hiroyuki wrote:
> On Mon, 23 Feb 2009 10:32:46 +0800
> Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> wrote:
> 
>> KAMEZAWA Hiroyuki wrote:
>>> Paul Menage さんは書きました：
>>>> On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki
>>>> <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> wrote:
>>>>> 2. /proc/mounts information of release_agent should be updated....
>>>>>   when it's overwritten directly.
>>>> Yes, definitely. But shouldn't that happen already?
>>>> cgroup_show_options() reports the current value of
>>>> root->release_agent_path in /proc/mounts. Is it possible that mount is
>>>> actually storing/retrieving this information in /etc/mtab, which
>>>> doesn't get updated?
>>>>
>>> Ah, you're right. /proc/mounts is updated but /etc/mtab is not updated.
>>> Hmm..from man mount(1), /etc/mtab is not synchronized with /proc/mounts.
>>> Do we need to allow release_agent override at remount ?
>>>
>> Since we've allowed this behavior, I think we shouldn't disallow it to
>> supprise users?
>>
> In a bit different stroy, it already surprises a user (me).
> for example)
> 

I think what may surprise people is the following mount will append opts
to the original opts.

> #mount -t cgroup none /cgroups -ocpu,release_agent=hogehoge
> #mount -oremount,cpuacct /cgroups,release_agent=xxxx
> => remount fails. because the option "release_agent" appears twice.
> 
> #mount -t cgroup none /cgroups -ocpu,release_agent=hogehoge
> #mount -t cgroup none /cgroups -oremount,cpuacct /cgroups,release_agent=xxxx
> => remount success.
> 
> At least, updating documentation to notice this is necessary I think.
> 

How about this:

[PATCH] cgroups: more documentation for remount and release_agent

This won't remove cpuacct from the mounted hierachy:
 # mount -t cgroup -o cpu,cpuacct xxx /mnt
 # mount -o remount,cpu /mnt

Because for this usage mount(8) will append the new options to the original
options.

And this will get you right:
 # mount [-t cgroup] -o remount,cpu xxx /mnt

Also document how to specify and change release_agent.

Signed-off-by: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
---
diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt
index 93feb84..824277d 100644
--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@@ -337,8 +337,19 @@ subsystems, type:
 
 To change the set of subsystems bound to a mounted hierarchy, just
 remount with different options:
+# mount -o remount,cpuset,ns hier1 /dev/cgroup
 
-# mount -o remount,cpuset,ns  /dev/cgroup
+Now numtasks is removed from the hierarchy and ns is added.
+
+Note this will add ns to the hierarchy but won't remove numtasks or
+cpuset:
+# mount -o remount,ns /dev/cgroup
+
+To Specify a hierarchy's release_agent:
+# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
+  xxx /dev/cgroup
+
+Note that specifying 'release_agent' more than once will return failure.
 
 Note that changing the set of subsystems is currently only supported
 when the hierarchy consists of a single (root) cgroup. Supporting
@@ -349,6 +360,11 @@ Then under /dev/cgroup you can find a tree that corresponds to the
 tree of the cgroups in the system. For instance, /dev/cgroup
 is the cgroup that holds the whole system.
 
+If you want to change the value of release_agent:
+# echo "/sbin/new_release_agent" > /dev/cgroup/release_agent
+
+It can also be changed via remount.
+
 If you want to create a new cgroup under /dev/cgroup:
 # cd /dev/cgroup
 # mkdir my_cgroup

Re: Question for remount

[Li Zefan]

KAMEZAWA Hiroyuki wrote:
> On Mon, 23 Feb 2009 10:32:46 +0800
> Li Zefan <lizf@cn.fujitsu.com> wrote:
> 
>> KAMEZAWA Hiroyuki wrote:
>>> Paul Menage さんは書きました：
>>>> On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki
>>>> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>>>>> 2. /proc/mounts information of release_agent should be updated....
>>>>>   when it's overwritten directly.
>>>> Yes, definitely. But shouldn't that happen already?
>>>> cgroup_show_options() reports the current value of
>>>> root->release_agent_path in /proc/mounts. Is it possible that mount is
>>>> actually storing/retrieving this information in /etc/mtab, which
>>>> doesn't get updated?
>>>>
>>> Ah, you're right. /proc/mounts is updated but /etc/mtab is not updated.
>>> Hmm..from man mount(1), /etc/mtab is not synchronized with /proc/mounts.
>>> Do we need to allow release_agent override at remount ?
>>>
>> Since we've allowed this behavior, I think we shouldn't disallow it to
>> supprise users?
>>
> In a bit different stroy, it already surprises a user (me).
> for example)
> 

I think what may surprise people is the following mount will append opts
to the original opts.

> #mount -t cgroup none /cgroups -ocpu,release_agent=hogehoge
> #mount -oremount,cpuacct /cgroups,release_agent=xxxx
> => remount fails. because the option "release_agent" appears twice.
> 
> #mount -t cgroup none /cgroups -ocpu,release_agent=hogehoge
> #mount -t cgroup none /cgroups -oremount,cpuacct /cgroups,release_agent=xxxx
> => remount success.
> 
> At least, updating documentation to notice this is necessary I think.
> 

How about this:

[PATCH] cgroups: more documentation for remount and release_agent

This won't remove cpuacct from the mounted hierachy:
 # mount -t cgroup -o cpu,cpuacct xxx /mnt
 # mount -o remount,cpu /mnt

Because for this usage mount(8) will append the new options to the original
options.

And this will get you right:
 # mount [-t cgroup] -o remount,cpu xxx /mnt

Also document how to specify and change release_agent.

Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
---
diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt
index 93feb84..824277d 100644
--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@@ -337,8 +337,19 @@ subsystems, type:
 
 To change the set of subsystems bound to a mounted hierarchy, just
 remount with different options:
+# mount -o remount,cpuset,ns hier1 /dev/cgroup
 
-# mount -o remount,cpuset,ns  /dev/cgroup
+Now numtasks is removed from the hierarchy and ns is added.
+
+Note this will add ns to the hierarchy but won't remove numtasks or
+cpuset:
+# mount -o remount,ns /dev/cgroup
+
+To Specify a hierarchy's release_agent:
+# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
+  xxx /dev/cgroup
+
+Note that specifying 'release_agent' more than once will return failure.
 
 Note that changing the set of subsystems is currently only supported
 when the hierarchy consists of a single (root) cgroup. Supporting
@@ -349,6 +360,11 @@ Then under /dev/cgroup you can find a tree that corresponds to the
 tree of the cgroups in the system. For instance, /dev/cgroup
 is the cgroup that holds the whole system.
 
+If you want to change the value of release_agent:
+# echo "/sbin/new_release_agent" > /dev/cgroup/release_agent
+
+It can also be changed via remount.
+
 If you want to create a new cgroup under /dev/cgroup:
 # cd /dev/cgroup
 # mkdir my_cgroup

Re: Question for remount

[KAMEZAWA Hiroyuki]

Paul Menage さんは書きました：
> On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> wrote:
>>
>> 2. /proc/mounts information of release_agent should be updated....
>>   when it's overwritten directly.
>
> Yes, definitely. But shouldn't that happen already?
> cgroup_show_options() reports the current value of
> root->release_agent_path in /proc/mounts. Is it possible that mount is
> actually storing/retrieving this information in /etc/mtab, which
> doesn't get updated?
>
Ah, you're right. /proc/mounts is updated but /etc/mtab is not updated.
Hmm..from man mount(1), /etc/mtab is not synchronized with /proc/mounts.
Do we need to allow release_agent override at remount ?

-Kame

Re: Question for remount

[Li Zefan]

> 1. Documentation/cgroups/cgroup.txt says
>    #mount -oremount,cpuset,ns /dev/cgroup
>    But this should be
>    #mount -tcgroup none /dev/cgroup -oremount,cpuset,ns
> 

I agree. Actually I noticed this long ago.

Doing this won't remove cpuacct from the cgroup hierarchy:
# mount -t cgroup -o cpu,cpuacct xxx /mnt
# mount -o remount,cpu /mnt
This will get you right:
# mount [-t cgroup] -o remount,cpu xxx /mnt

Re: Question for remount

[Li Zefan]

Li Zefan wrote:
>> 1. Documentation/cgroups/cgroup.txt says
>>    #mount -oremount,cpuset,ns /dev/cgroup
>>    But this should be
>>    #mount -tcgroup none /dev/cgroup -oremount,cpuset,ns
>>
> 
> I agree. Actually I noticed this long ago.
> 
> Doing this won't remove cpuacct from the cgroup hierarchy:
> # mount -t cgroup -o cpu,cpuacct xxx /mnt
> # mount -o remount,cpu /mnt
> This will get you right:
> # mount [-t cgroup] -o remount,cpu xxx /mnt
> 

How about this patch:

[PATCH] cgroups: fix documentation about remount

This won't remove cpuacct from the mounted hierachy:
 # mount -t cgroup -o cpu,cpuacct xxx /mnt
 # mount -o remount,cpu /mnt

Because for this usage mount(8) will append the new options to the current
options.

And this will get you right:
 # mount [-t cgroup] -o remount,cpu xxx /mnt

Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
---
 Documentation/cgroups/cgroups.txt |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt
index 93feb84..5cbeab2 100644
--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@@ -337,8 +337,13 @@ subsystems, type:
 
 To change the set of subsystems bound to a mounted hierarchy, just
 remount with different options:
+# mount -o remount,cpuset,ns hier1 /dev/cgroup
 
-# mount -o remount,cpuset,ns  /dev/cgroup
+Now numtasks is removed from the hierarchy and ns is added.
+
+Note this will add ns to the hierarchy but won't remove numtasks or
+cpuset:
+# mount -o remount,ns /dev/cgroup
 
 Note that changing the set of subsystems is currently only supported
 when the hierarchy consists of a single (root) cgroup. Supporting
-- 
1.5.4.rc3

Re: Question for remount

[KAMEZAWA Hiroyuki]

On Mon, 23 Feb 2009 10:56:04 +0800
Li Zefan <lizf@cn.fujitsu.com> wrote:

> Li Zefan wrote:
> >> 1. Documentation/cgroups/cgroup.txt says
> >>    #mount -oremount,cpuset,ns /dev/cgroup
> >>    But this should be
> >>    #mount -tcgroup none /dev/cgroup -oremount,cpuset,ns
> >>
> > 
> > I agree. Actually I noticed this long ago.
> > 
> > Doing this won't remove cpuacct from the cgroup hierarchy:
> > # mount -t cgroup -o cpu,cpuacct xxx /mnt
> > # mount -o remount,cpu /mnt
> > This will get you right:
> > # mount [-t cgroup] -o remount,cpu xxx /mnt
> > 
> 
> How about this patch:
> 
> [PATCH] cgroups: fix documentation about remount
> 
> This won't remove cpuacct from the mounted hierachy:
>  # mount -t cgroup -o cpu,cpuacct xxx /mnt
>  # mount -o remount,cpu /mnt
> 
> Because for this usage mount(8) will append the new options to the current
> options.
> 
> And this will get you right:
>  # mount [-t cgroup] -o remount,cpu xxx /mnt
> 
> Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
> ---
>  Documentation/cgroups/cgroups.txt |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt
> index 93feb84..5cbeab2 100644
> --- a/Documentation/cgroups/cgroups.txt
> +++ b/Documentation/cgroups/cgroups.txt
> @@ -337,8 +337,13 @@ subsystems, type:
>  
>  To change the set of subsystems bound to a mounted hierarchy, just
>  remount with different options:
> +# mount -o remount,cpuset,ns hier1 /dev/cgroup
>  
> -# mount -o remount,cpuset,ns  /dev/cgroup
> +Now numtasks is removed from the hierarchy and ns is added.
> +
> +Note this will add ns to the hierarchy but won't remove numtasks or
> +cpuset:
> +# mount -o remount,ns /dev/cgroup
>  

Just a question. What is "numtasks" here ? We have numtasks cgroup ?

Thanks,
-Kame




>  Note that changing the set of subsystems is currently only supported
>  when the hierarchy consists of a single (root) cgroup. Supporting
> -- 
> 1.5.4.rc3
> 

Re: Question for remount

[Li Zefan]

>>  To change the set of subsystems bound to a mounted hierarchy, just
>>  remount with different options:
>> +# mount -o remount,cpuset,ns hier1 /dev/cgroup
>>  
>> -# mount -o remount,cpuset,ns  /dev/cgroup
>> +Now numtasks is removed from the hierarchy and ns is added.
>> +
>> +Note this will add ns to the hierarchy but won't remove numtasks or
>> +cpuset:
>> +# mount -o remount,ns /dev/cgroup
>>  
> 
> Just a question. What is "numtasks" here ? We have numtasks cgroup ?
> 

No, I guess that's a proposed but not implemented cgroup subsystem. :)
And I can change it to an existing one.

Re: Question for remount

[KAMEZAWA Hiroyuki]

On Tue, 24 Feb 2009 09:41:28 +0800
Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> wrote:

> >>  To change the set of subsystems bound to a mounted hierarchy, just
> >>  remount with different options:
> >> +# mount -o remount,cpuset,ns hier1 /dev/cgroup
> >>  
> >> -# mount -o remount,cpuset,ns  /dev/cgroup
> >> +Now numtasks is removed from the hierarchy and ns is added.
> >> +
> >> +Note this will add ns to the hierarchy but won't remove numtasks or
> >> +cpuset:
> >> +# mount -o remount,ns /dev/cgroup
> >>  
> > 
> > Just a question. What is "numtasks" here ? We have numtasks cgroup ?
> > 
> 
> No, I guess that's a proposed but not implemented cgroup subsystem. :)
> And I can change it to an existing one.
> 
O.K. thanks.

BTW, how about writing this kind of text in explicit way ?
+Note: this will add ns to the hierarchy but won't remove numtasks or
+cpuset because new options is appended to old options. If you want to
+override, please use.....

-Kame

Re: Question for remount

[KAMEZAWA Hiroyuki]

On Tue, 24 Feb 2009 09:41:28 +0800
Li Zefan <lizf@cn.fujitsu.com> wrote:

> >>  To change the set of subsystems bound to a mounted hierarchy, just
> >>  remount with different options:
> >> +# mount -o remount,cpuset,ns hier1 /dev/cgroup
> >>  
> >> -# mount -o remount,cpuset,ns  /dev/cgroup
> >> +Now numtasks is removed from the hierarchy and ns is added.
> >> +
> >> +Note this will add ns to the hierarchy but won't remove numtasks or
> >> +cpuset:
> >> +# mount -o remount,ns /dev/cgroup
> >>  
> > 
> > Just a question. What is "numtasks" here ? We have numtasks cgroup ?
> > 
> 
> No, I guess that's a proposed but not implemented cgroup subsystem. :)
> And I can change it to an existing one.
> 
O.K. thanks.

BTW, how about writing this kind of text in explicit way ?
+Note: this will add ns to the hierarchy but won't remove numtasks or
+cpuset because new options is appended to old options. If you want to
+override, please use.....

-Kame

Re: Question for remount

[Li Zefan]

>>  To change the set of subsystems bound to a mounted hierarchy, just
>>  remount with different options:
>> +# mount -o remount,cpuset,ns hier1 /dev/cgroup
>>  
>> -# mount -o remount,cpuset,ns  /dev/cgroup
>> +Now numtasks is removed from the hierarchy and ns is added.
>> +
>> +Note this will add ns to the hierarchy but won't remove numtasks or
>> +cpuset:
>> +# mount -o remount,ns /dev/cgroup
>>  
> 
> Just a question. What is "numtasks" here ? We have numtasks cgroup ?
> 

No, I guess that's a proposed but not implemented cgroup subsystem. :)
And I can change it to an existing one.

Re: Question for remount

[KAMEZAWA Hiroyuki]

On Mon, 23 Feb 2009 10:56:04 +0800
Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> wrote:

> Li Zefan wrote:
> >> 1. Documentation/cgroups/cgroup.txt says
> >>    #mount -oremount,cpuset,ns /dev/cgroup
> >>    But this should be
> >>    #mount -tcgroup none /dev/cgroup -oremount,cpuset,ns
> >>
> > 
> > I agree. Actually I noticed this long ago.
> > 
> > Doing this won't remove cpuacct from the cgroup hierarchy:
> > # mount -t cgroup -o cpu,cpuacct xxx /mnt
> > # mount -o remount,cpu /mnt
> > This will get you right:
> > # mount [-t cgroup] -o remount,cpu xxx /mnt
> > 
> 
> How about this patch:
> 
> [PATCH] cgroups: fix documentation about remount
> 
> This won't remove cpuacct from the mounted hierachy:
>  # mount -t cgroup -o cpu,cpuacct xxx /mnt
>  # mount -o remount,cpu /mnt
> 
> Because for this usage mount(8) will append the new options to the current
> options.
> 
> And this will get you right:
>  # mount [-t cgroup] -o remount,cpu xxx /mnt
> 
> Signed-off-by: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
> ---
>  Documentation/cgroups/cgroups.txt |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt
> index 93feb84..5cbeab2 100644
> --- a/Documentation/cgroups/cgroups.txt
> +++ b/Documentation/cgroups/cgroups.txt
> @@ -337,8 +337,13 @@ subsystems, type:
>  
>  To change the set of subsystems bound to a mounted hierarchy, just
>  remount with different options:
> +# mount -o remount,cpuset,ns hier1 /dev/cgroup
>  
> -# mount -o remount,cpuset,ns  /dev/cgroup
> +Now numtasks is removed from the hierarchy and ns is added.
> +
> +Note this will add ns to the hierarchy but won't remove numtasks or
> +cpuset:
> +# mount -o remount,ns /dev/cgroup
>  

Just a question. What is "numtasks" here ? We have numtasks cgroup ?

Thanks,
-Kame




>  Note that changing the set of subsystems is currently only supported
>  when the hierarchy consists of a single (root) cgroup. Supporting
> -- 
> 1.5.4.rc3
> 

Re: Question for remount

[Li Zefan]

Li Zefan wrote:
>> 1. Documentation/cgroups/cgroup.txt says
>>    #mount -oremount,cpuset,ns /dev/cgroup
>>    But this should be
>>    #mount -tcgroup none /dev/cgroup -oremount,cpuset,ns
>>
> 
> I agree. Actually I noticed this long ago.
> 
> Doing this won't remove cpuacct from the cgroup hierarchy:
> # mount -t cgroup -o cpu,cpuacct xxx /mnt
> # mount -o remount,cpu /mnt
> This will get you right:
> # mount [-t cgroup] -o remount,cpu xxx /mnt
> 

How about this patch:

[PATCH] cgroups: fix documentation about remount

This won't remove cpuacct from the mounted hierachy:
 # mount -t cgroup -o cpu,cpuacct xxx /mnt
 # mount -o remount,cpu /mnt

Because for this usage mount(8) will append the new options to the current
options.

And this will get you right:
 # mount [-t cgroup] -o remount,cpu xxx /mnt

Signed-off-by: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
---
 Documentation/cgroups/cgroups.txt |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt
index 93feb84..5cbeab2 100644
--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@@ -337,8 +337,13 @@ subsystems, type:
 
 To change the set of subsystems bound to a mounted hierarchy, just
 remount with different options:
+# mount -o remount,cpuset,ns hier1 /dev/cgroup
 
-# mount -o remount,cpuset,ns  /dev/cgroup
+Now numtasks is removed from the hierarchy and ns is added.
+
+Note this will add ns to the hierarchy but won't remove numtasks or
+cpuset:
+# mount -o remount,ns /dev/cgroup
 
 Note that changing the set of subsystems is currently only supported
 when the hierarchy consists of a single (root) cgroup. Supporting
-- 
1.5.4.rc3

Re: Question for remount

[Paul Menage]

On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki
<kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> wrote:
>
> 2. /proc/mounts information of release_agent should be updated....
>   when it's overwritten directly.

Yes, definitely. But shouldn't that happen already?
cgroup_show_options() reports the current value of
root->release_agent_path in /proc/mounts. Is it possible that mount is
actually storing/retrieving this information in /etc/mtab, which
doesn't get updated?

Paul

Re: Question for remount

[Li Zefan]

> 1. Documentation/cgroups/cgroup.txt says
>    #mount -oremount,cpuset,ns /dev/cgroup
>    But this should be
>    #mount -tcgroup none /dev/cgroup -oremount,cpuset,ns
> 

I agree. Actually I noticed this long ago.

Doing this won't remove cpuacct from the cgroup hierarchy:
# mount -t cgroup -o cpu,cpuacct xxx /mnt
# mount -o remount,cpu /mnt
This will get you right:
# mount [-t cgroup] -o remount,cpu xxx /mnt

Question for remount

[KAMEZAWA Hiroyuki]

Followings are 3 stories of remount cgroup,

1. remount with devices.

 # mount -t cgroup none /cgroups -ocpuacct,release_agent=xxx
 # echo > /cgroups/release_agent #clear release agent by hand
 # mount -t cgroup none /cgroups -oremount,cpuacct
 # cat /cgroups/release_agent
   => release_agent is ""

2. remount without devices, mount command will read /proc/mounts and
   copies option.

 # mount -t cgroup none /cgroups -ocpuacct,release_agent=xxx
 # echo > /cgroups/release_agent      #clear release agent by hand
 # mount /cgroups -oremount,cpuacct   #don't specify device
 # cat /cgroups/release_agent
   => xxx

Hmm, release_agent is copied from /proc/mounts and release_agent revives.

3. remount without devices, mount command will read /proc/mounts
 # mount -t cgroup none /cgroups -ocpuacct,release_agent=xxx
 # mount /cgroups -oremount,cpuacct,release_agent=xxx
 => error
 "release_agent=" will be found twice and this returns -INVAL

maybe case "2" is not ideal, I think. (but it may not be bug.)

My point is following.

1. Documentation/cgroups/cgroup.txt says
   #mount -oremount,cpuset,ns /dev/cgroup
   But this should be
   #mount -tcgroup none /dev/cgroup -oremount,cpuset,ns

2. /proc/mounts information of release_agent should be updated....
   when it's overwritten directly.

3. If "2" is impossible, changing release_agent at remount should not be allowed.

How do you think ?

Thanks,
-Kame