* Question for remount
@ 2009-02-20 10:02 KAMEZAWA Hiroyuki
2009-02-20 16:22 ` Paul Menage
2009-02-23 2:27 ` Li Zefan
0 siblings, 2 replies; 11+ messages in thread
From: KAMEZAWA Hiroyuki @ 2009-02-20 10:02 UTC (permalink / raw)
To: linux-kernel; +Cc: menage, lizf, containers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Question for remount
2009-02-20 10:02 Question for remount KAMEZAWA Hiroyuki
@ 2009-02-20 16:22 ` Paul Menage
2009-02-21 0:45 ` KAMEZAWA Hiroyuki
2009-02-23 2:27 ` Li Zefan
1 sibling, 1 reply; 11+ messages in thread
From: Paul Menage @ 2009-02-20 16:22 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linux-kernel, lizf, containers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Question for remount
2009-02-20 16:22 ` Paul Menage
@ 2009-02-21 0:45 ` KAMEZAWA Hiroyuki
2009-02-23 2:32 ` Li Zefan
0 siblings, 1 reply; 11+ messages in thread
From: KAMEZAWA Hiroyuki @ 2009-02-21 0:45 UTC (permalink / raw)
To: Paul Menage; +Cc: KAMEZAWA Hiroyuki, linux-kernel, lizf, containers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Question for remount
2009-02-20 10:02 Question for remount KAMEZAWA Hiroyuki
2009-02-20 16:22 ` Paul Menage
@ 2009-02-23 2:27 ` Li Zefan
2009-02-23 2:56 ` Li Zefan
1 sibling, 1 reply; 11+ messages in thread
From: Li Zefan @ 2009-02-23 2:27 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linux-kernel, menage, containers
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Question for remount
2009-02-21 0:45 ` KAMEZAWA Hiroyuki
@ 2009-02-23 2:32 ` Li Zefan
2009-02-23 23:57 ` KAMEZAWA Hiroyuki
0 siblings, 1 reply; 11+ messages in thread
From: Li Zefan @ 2009-02-23 2:32 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: Paul Menage, linux-kernel, containers
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?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Question for remount
2009-02-23 2:27 ` Li Zefan
@ 2009-02-23 2:56 ` Li Zefan
2009-02-24 1:36 ` KAMEZAWA Hiroyuki
0 siblings, 1 reply; 11+ messages in thread
From: Li Zefan @ 2009-02-23 2:56 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linux-kernel, menage, containers
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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: Question for remount
2009-02-23 2:32 ` Li Zefan
@ 2009-02-23 23:57 ` KAMEZAWA Hiroyuki
2009-02-24 1:33 ` Li Zefan
0 siblings, 1 reply; 11+ messages in thread
From: KAMEZAWA Hiroyuki @ 2009-02-23 23:57 UTC (permalink / raw)
To: Li Zefan; +Cc: Paul Menage, linux-kernel, containers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Question for remount
2009-02-23 23:57 ` KAMEZAWA Hiroyuki
@ 2009-02-24 1:33 ` Li Zefan
0 siblings, 0 replies; 11+ messages in thread
From: Li Zefan @ 2009-02-24 1:33 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: Paul Menage, linux-kernel, containers
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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: Question for remount
2009-02-23 2:56 ` Li Zefan
@ 2009-02-24 1:36 ` KAMEZAWA Hiroyuki
2009-02-24 1:41 ` Li Zefan
0 siblings, 1 reply; 11+ messages in thread
From: KAMEZAWA Hiroyuki @ 2009-02-24 1:36 UTC (permalink / raw)
To: Li Zefan; +Cc: linux-kernel, menage, containers
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Question for remount
2009-02-24 1:36 ` KAMEZAWA Hiroyuki
@ 2009-02-24 1:41 ` Li Zefan
2009-02-24 1:47 ` KAMEZAWA Hiroyuki
0 siblings, 1 reply; 11+ messages in thread
From: Li Zefan @ 2009-02-24 1:41 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linux-kernel, menage, containers
>> 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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Question for remount
2009-02-24 1:41 ` Li Zefan
@ 2009-02-24 1:47 ` KAMEZAWA Hiroyuki
0 siblings, 0 replies; 11+ messages in thread
From: KAMEZAWA Hiroyuki @ 2009-02-24 1:47 UTC (permalink / raw)
To: Li Zefan; +Cc: linux-kernel, menage, containers
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2009-02-24 1:49 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-20 10:02 Question for remount KAMEZAWA Hiroyuki
2009-02-20 16:22 ` Paul Menage
2009-02-21 0:45 ` KAMEZAWA Hiroyuki
2009-02-23 2:32 ` Li Zefan
2009-02-23 23:57 ` KAMEZAWA Hiroyuki
2009-02-24 1:33 ` Li Zefan
2009-02-23 2:27 ` Li Zefan
2009-02-23 2:56 ` Li Zefan
2009-02-24 1:36 ` KAMEZAWA Hiroyuki
2009-02-24 1:41 ` Li Zefan
2009-02-24 1:47 ` KAMEZAWA Hiroyuki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).