On 08/12/2011 08:04 PM, Dhaval Giani wrote:
> On Fri, Aug 12, 2011 at 2:21 AM, Balbir Singh<bsinghar...@gmail.com> wrote:
>> On Sat, Aug 6, 2011 at 11:25 PM, Raghavendra KT
>> <raghavendra...@gmail.com> wrote:
>>> Yes, I do agree. I retested with -git, it is not unmounting/touching the
>>> subsystems that are already mounted. and unmounting all the controllers ( As
>>> I saw it to be doing earlier) was not probably the correct behaviour.
>>
>> Okay, so do we need this? Can you please describe the patch with a use
>> case I can test?
>
> The patch is invalid.
>
> Dhaval
I do not want to put that the patch is entirely invalid. It is
debatable, rather I would say,
the current implementation seemed to be more sensible than my patch.
Feel free to correct if I am logically/technically wrong. Let me explain
with simple scenario/usecase.
Configuration:
[root@oc5400248562 ]# cat /etc/cgconfig.conf
mount {
cpuset = /cgroup/cpuset;
cpu = /cgroup/cpu;
cpuacct = /cgroup/cpuacct;
memory = /cgroup/memory;
devices = /cgroup/devices;
freezer = /cgroup/freezer;
net_cls = /cgroup/net_cls;
ns = /cgroup/ns;
blkio = /cgroup/blkio;
}
[root@oc5400248562 ]# mkdir -p /cgroup/memory
[root@oc5400248562 ]# mount -t cgroup tmpfs /cgroup/memory -o memory
Now suppose user wants to start cgconfig service
Behaviour 1 (B1)
==============
[root@oc5400248562 ]# service cgconfig start
Starting cgconfig service: Loading configuration file /etc/cgconfig.conf
failed
Cgroup mounting failed
Failed to parse /etc/cgconfig.conf [FAILED]
[root@oc5400248562 ]# service cgconfig start
Starting cgconfig service: [ OK ]
Behaviour 2 (B2)
============
[root@oc5400248562 ]# service cgconfig start
Starting cgconfig service: [ OK ]
Behaviour 3 (B3)
============
[root@oc5400248562 ]# service cgconfig start
Starting cgconfig service: Loading configuration file /etc/cgconfig.conf
failed
Cgroup mounting failed
Failed to parse /etc/cgconfig.conf [FAILED]
[root@oc5400248562 ]# service cgconfig start
Starting cgconfig service: Loading configuration file /etc/cgconfig.conf
failed
Cgroup mounting failed
Failed to parse /etc/cgconfig.conf [FAILED]
B1 is observed in early libcg ( as far as I know < 0.37.1 or so). Where
in which whenever a subsystem can not be mounted by cgconfigparser, it
unmounts all the subsystem it mounted, as well as that were present
earlier in error handling path. So if user retries to start service,
he succeeds. This is **entirely invalid** behaviour.
B2 corresponds to my patch where in which instead of unmounting all
subsystem in error path, it tries to unmount first and retries mounting
all the subsystem. In the usecase given, instead of unmounting memory
explicitly, and then retrying, we can see that it silently succeeds (may
be a warning was more meaningful).
B3 is what is seen now in mainline, it is seem to be logically sound, in
the sense it does not touch the previously mounted subsystem, it is
irritating for the user who supposedly has mounted one subsystem and
wants to see 5 subsystem to be mounted, with the continuous
complaints. Every time, when even a single subsystem is mounted, he
would have to do manually unmount/cgclear.
In my opinion this is not the only best option we can have.
1.How about continuing with the mounting of other subsystems even if we
notice, one/more of subsystem is mounted ? (B4)
2.How about having a tunable, leaving the option to the user the way he
wishes the behaviour to be either B2/B3/B4?
Raghavendra
------------------------------------------------------------------------------
FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
Subversion made easy with a complete admin console. Easy
to use, easy to manage, easy to install, easy to extend.
Get a Free download of the new open ALM Subversion platform now.
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Libcg-devel mailing list
Libcg-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libcg-devel
