[Devel] Re: cgroup mount point

[Thadeu Lima de Souza Cascardo]

On Mon, Feb 02, 2009 at 04:54:58PM -0600, Chris Friesen wrote:
> Thadeu Lima de Souza Cascardo wrote:
>
>> Linux Documentation is not consistent and have some funny options. In
>> Documentation/cgroups/*, we have:
>
>> So, we have some more options now: /cgroups, /containers, /dev/cpuset,
>> /dev/cpuctl, /opt/cgroup, /opt/cpuset.
>>
>> I am copying the container and the kernel guys. Perhaps, we can find an
>> agreement (if we want to find one at all) and change all that
>> Documentation to get consistent.
>
> I'd vote for "cgroups" or "containers", mounted at / or /sys/.
>
> /opt feels more like where software should live, and /dev should be for  
> devices rather than capabilities/management.  "cpuctl" and "cpuset" are  
> subsets of the full capabilities of cgroups, so they're suboptimal as  
> far as naming.
>
> Chris

Since the original post didn't go to lkml or lxc, here it is. Sorry d-d,
but I want to keep it in the loop.

And I agree with Chris in regards that cpuctl and cpuset are not only
what is provided under a cgroup mountpoint, so they are not very good
options. I prefer cgroup over container, and I prefer the singular.

However, I'd rather not see this in /sys/ for the reason stated below.
But since we may end up agreeing on this with the kernel people, we
would be safe not to clash with a /sys/cgroup. But I see no problems
with /dev/cgroup/ but would also be glad to see /cgroup/ as the choice.


--
Hello,

Some software I intend to package work with the new cgroup feature in
Linux. I would like to open a discussion about what would be the better
place to mount it and how/when to mount it.

Some of the options are:


/sys/cgroup
/proc/cgroup

These two would not be very wise, since some kernel change may create
those two, and, then, we would hide them, at least. /proc/cgroups, for
example, is already there.


/cgroup

The FHS says why we should not create a new subdirectory in the root
filesystem:

1) "It demands space on a root partition which the system administrator
may want kept small and simple for either performance or security
reasons."

This does not apply here, since we do not require any storage for
/cgroup, but for the directory entry itself.

2) "It evades whatever discipline the system administrator may have set
up for distributing standard file hierarchies across mountable volumes."

Since /cgroup is totally local, I can't see why this will evade
anything.

procfs and sysfs are in the root filesystem too. So why not put /cgroup
there?


/dev/cgroup

Many people have been using this. FHS says this "is the location for
special and device files." What is not special about cgroup anyway?



After deciding where to mount it, we may write some code for some of the
init scripts to mount it. I think mountkernfs.sh may be a good place,
since it also mounts /proc and /sys.

Any opinions and comments appreciated.

Regards,
Cascardo.
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.openvz.org/pipermail/devel/attachments/20090202/d11f378e/attachment-0001.sig>
-------------- next part --------------
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers