Re: cgroup mount point

Re: cgroup mount point

[Thadeu Lima de Souza Cascardo]

[-- Attachment #1.1: Type: text/plain, Size: 1562 bytes --]

On Mon, Feb 02, 2009 at 09:52:46PM +0100, Mike Hommey wrote:
> On Mon, Feb 02, 2009 at 09:26:11PM +0100, Julien Cristau wrote:
> > On Mon, 2009-02-02 at 18:00 -0200, Thadeu Lima de Souza Cascardo wrote:
> > > 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.
> > 
> > What do other distros use?
> 
> Even better: what do the kernel folks want to do?
> 
> Mike

From what I've seen, most of them are in the same phases as Debian, or,
perhaps, behind. Fedora seems to plan that for Fedora 11, and they have
some support in libvirt.

Linux Documentation is not consistent and have some funny options. In
Documentation/cgroups/*, we have:

cgroups.txt:
/dev/cgroup

cpuacct.txt:
/cgroups

devices.txt:
/cgroups

memcg_test.txt:
/opt/cgroup
/opt/cpuset
/cgroup

memory.txt:
/cgroups

cpusets.txt:
/dev/cpuset

freezer-subsystem.txt:
/containers

There is also:

Documentation/scheduler/sched-design-CFS.txt:
/dev/cpuctl
/cgroup

Documentation/scheduler/sched-rt-group.txt:
/cgroup

Documentation/accounting/cgroupstats.txt:
/cgroup


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.

Regards,
Cascardo.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Re: cgroup mount point

[Thadeu Lima de Souza Cascardo]

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]

On Mon, Feb 02, 2009 at 09:52:46PM +0100, Mike Hommey wrote:
> On Mon, Feb 02, 2009 at 09:26:11PM +0100, Julien Cristau wrote:
> > On Mon, 2009-02-02 at 18:00 -0200, Thadeu Lima de Souza Cascardo wrote:
> > > 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.
> > 
> > What do other distros use?
> 
> Even better: what do the kernel folks want to do?
> 
> Mike

From what I've seen, most of them are in the same phases as Debian, or,
perhaps, behind. Fedora seems to plan that for Fedora 11, and they have
some support in libvirt.

Linux Documentation is not consistent and have some funny options. In
Documentation/cgroups/*, we have:

cgroups.txt:
/dev/cgroup

cpuacct.txt:
/cgroups

devices.txt:
/cgroups

memcg_test.txt:
/opt/cgroup
/opt/cpuset
/cgroup

memory.txt:
/cgroups

cpusets.txt:
/dev/cpuset

freezer-subsystem.txt:
/containers

There is also:

Documentation/scheduler/sched-design-CFS.txt:
/dev/cpuctl
/cgroup

Documentation/scheduler/sched-rt-group.txt:
/cgroup

Documentation/accounting/cgroupstats.txt:
/cgroup


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.

Regards,
Cascardo.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: cgroup mount point

[Chris Friesen]

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

Re: cgroup mount point

[Daniel P. Berrange]

On Mon, Feb 02, 2009 at 07:41:53PM -0200, Thadeu Lima de Souza Cascardo wrote:
> On Mon, Feb 02, 2009 at 09:52:46PM +0100, Mike Hommey wrote:
> > On Mon, Feb 02, 2009 at 09:26:11PM +0100, Julien Cristau wrote:
> > > On Mon, 2009-02-02 at 18:00 -0200, Thadeu Lima de Souza Cascardo wrote:
> > > > 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.
> > > 
> > > What do other distros use?
> > 
> > Even better: what do the kernel folks want to do?
> > 
> > Mike
> 
> From what I've seen, most of them are in the same phases as Debian, or,
> perhaps, behind. Fedora seems to plan that for Fedora 11, and they have
> some support in libvirt.

libvirt is not going to impose any policy for mount points, nor mount
anything itself. When we use cgroups, libvirt just looks up the mount
table to find out where the admin or distro has put the mount points
for each cgroups controller.

I've also not done anything in default Fedora install to automatically
setup cgroups, since doing that hits the hard-to-answer question of
whether to mount all controllers in one, or a separate mount per
controller, or a hybrid.

> So, we have some more options now: /cgroups, /containers, /dev/cpuset,
> /dev/cpuctl, /opt/cgroup, /opt/cpuset.

Putting new mount points in / is not really acceptable, so that rules
out the first two. /opt is just totally wrong, since that is intended
for add on software packages. /dev/ feels a little odd, since it is
not really device nodes, but perhaps that doesn't matter. So my pref
would be something in /dev/cgroups or /sys/cgroups

I also think 'cgroups' is a better name than 'containers', since 
'containers' is refering to just one specific use case.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: cgroup mount point

[Chris Friesen]

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

Re: cgroup mount point

[Thadeu Lima de Souza Cascardo]

[-- Attachment #1: Type: text/plain, Size: 2996 bytes --]

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.
--

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: cgroup mount point

[KAMEZAWA Hiroyuki]

On Mon, 02 Feb 2009 16:54:58 -0600
"Chris Friesen" <cfriesen@nortel.com> 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/.
> 
me, too.

But single mount point just assumes "all necessary subsystems are mounter at once"
So,
    /cgroup/<subsys>/       #this cannot handle multiple subsyses.
    or 
    /cgroup/some_nick_name  #just depends on users.

Hmm. Making documentation to use the same mount point is not so bad. But in real
usage, cgroup's mount point seems case-by-case. 
If libcgroup or libvirt shows some policy, it's good for users.

  /cgroup/<libcgroup's grouping nick name>/ ...

or some.

Thanks,
-Kame

> /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
> _______________________________________________
> Containers mailing list
> Containers@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
> 

Re: cgroup mount point

[Serge E. Hallyn]

Quoting KAMEZAWA Hiroyuki (kamezawa.hiroyu@jp.fujitsu.com):
> On Mon, 02 Feb 2009 16:54:58 -0600
> "Chris Friesen" <cfriesen@nortel.com> 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/.
> > 
> me, too.
> 
> But single mount point just assumes "all necessary subsystems are mounter at once"
> So,
>     /cgroup/<subsys>/       #this cannot handle multiple subsyses.
>     or 
>     /cgroup/some_nick_name  #just depends on users.
> 
> Hmm. Making documentation to use the same mount point is not so bad. But in real
> usage, cgroup's mount point seems case-by-case. 
> If libcgroup or libvirt shows some policy, it's good for users.
> 
>   /cgroup/<libcgroup's grouping nick name>/ ...

I'm lazy so I always use /cgroup or actually /cg.

I do the same thing with mounting /sys/kernel/security under /security,
so maybe /sys/cgroup actually makes sense :)

-serge

Re: cgroup mount point

[Balbir Singh]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-02-03 12:15:24]:

> On Mon, 02 Feb 2009 16:54:58 -0600
> "Chris Friesen" <cfriesen@nortel.com> 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/.
> > 
> me, too.
> 
> But single mount point just assumes "all necessary subsystems are mounter at once"
> So,
>     /cgroup/<subsys>/       #this cannot handle multiple subsyses.
>     or 
>     /cgroup/some_nick_name  #just depends on users.
> 
> Hmm. Making documentation to use the same mount point is not so bad. But in real
> usage, cgroup's mount point seems case-by-case. 
> If libcgroup or libvirt shows some policy, it's good for users.
> 
>   /cgroup/<libcgroup's grouping nick name>/ ...
> 
> or some.
> 

FYI for everyone

Please take a look at libcgroup (libcg.sf.net). Through the
configuration mechanism, we allow the controllers to be mounted at any
desired location and provide configuration persistence across machine
reboots. The configuration (as in created cgroups and controller mount
points) is controlled via a configuration file.

-- 
	Balbir

Re: cgroup mount point

[Serge E. Hallyn]

Quoting KAMEZAWA Hiroyuki (kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org):
> On Mon, 02 Feb 2009 16:54:58 -0600
> "Chris Friesen" <cfriesen-ZIRUuHA3oDzQT0dZR+AlfA@public.gmane.org> 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/.
> > 
> me, too.
> 
> But single mount point just assumes "all necessary subsystems are mounter at once"
> So,
>     /cgroup/<subsys>/       #this cannot handle multiple subsyses.
>     or 
>     /cgroup/some_nick_name  #just depends on users.
> 
> Hmm. Making documentation to use the same mount point is not so bad. But in real
> usage, cgroup's mount point seems case-by-case. 
> If libcgroup or libvirt shows some policy, it's good for users.
> 
>   /cgroup/<libcgroup's grouping nick name>/ ...

I'm lazy so I always use /cgroup or actually /cg.

I do the same thing with mounting /sys/kernel/security under /security,
so maybe /sys/cgroup actually makes sense :)

-serge

Re: cgroup mount point

[Balbir Singh]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> [2009-02-03 12:15:24]:

> On Mon, 02 Feb 2009 16:54:58 -0600
> "Chris Friesen" <cfriesen-ZIRUuHA3oDzQT0dZR+AlfA@public.gmane.org> 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/.
> > 
> me, too.
> 
> But single mount point just assumes "all necessary subsystems are mounter at once"
> So,
>     /cgroup/<subsys>/       #this cannot handle multiple subsyses.
>     or 
>     /cgroup/some_nick_name  #just depends on users.
> 
> Hmm. Making documentation to use the same mount point is not so bad. But in real
> usage, cgroup's mount point seems case-by-case. 
> If libcgroup or libvirt shows some policy, it's good for users.
> 
>   /cgroup/<libcgroup's grouping nick name>/ ...
> 
> or some.
> 

FYI for everyone

Please take a look at libcgroup (libcg.sf.net). Through the
configuration mechanism, we allow the controllers to be mounted at any
desired location and provide configuration persistence across machine
reboots. The configuration (as in created cgroups and controller mount
points) is controlled via a configuration file.

-- 
	Balbir

Re: cgroup mount point

[Thadeu Lima de Souza Cascardo]

[-- Attachment #1.1: Type: text/plain, Size: 2996 bytes --]

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.
--

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Re: cgroup mount point

[KAMEZAWA Hiroyuki]

On Mon, 02 Feb 2009 16:54:58 -0600
"Chris Friesen" <cfriesen-ZIRUuHA3oDzQT0dZR+AlfA@public.gmane.org> 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/.
> 
me, too.

But single mount point just assumes "all necessary subsystems are mounter at once"
So,
    /cgroup/<subsys>/       #this cannot handle multiple subsyses.
    or 
    /cgroup/some_nick_name  #just depends on users.

Hmm. Making documentation to use the same mount point is not so bad. But in real
usage, cgroup's mount point seems case-by-case. 
If libcgroup or libvirt shows some policy, it's good for users.

  /cgroup/<libcgroup's grouping nick name>/ ...

or some.

Thanks,
-Kame

> /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
> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linux-foundation.org/mailman/listinfo/containers
> 

Re: cgroup mount point

[Daniel P. Berrange]

On Mon, Feb 02, 2009 at 07:41:53PM -0200, Thadeu Lima de Souza Cascardo wrote:
> On Mon, Feb 02, 2009 at 09:52:46PM +0100, Mike Hommey wrote:
> > On Mon, Feb 02, 2009 at 09:26:11PM +0100, Julien Cristau wrote:
> > > On Mon, 2009-02-02 at 18:00 -0200, Thadeu Lima de Souza Cascardo wrote:
> > > > 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.
> > > 
> > > What do other distros use?
> > 
> > Even better: what do the kernel folks want to do?
> > 
> > Mike
> 
> From what I've seen, most of them are in the same phases as Debian, or,
> perhaps, behind. Fedora seems to plan that for Fedora 11, and they have
> some support in libvirt.

libvirt is not going to impose any policy for mount points, nor mount
anything itself. When we use cgroups, libvirt just looks up the mount
table to find out where the admin or distro has put the mount points
for each cgroups controller.

I've also not done anything in default Fedora install to automatically
setup cgroups, since doing that hits the hard-to-answer question of
whether to mount all controllers in one, or a separate mount per
controller, or a hybrid.

> So, we have some more options now: /cgroups, /containers, /dev/cpuset,
> /dev/cpuctl, /opt/cgroup, /opt/cpuset.

Putting new mount points in / is not really acceptable, so that rules
out the first two. /opt is just totally wrong, since that is intended
for add on software packages. /dev/ feels a little odd, since it is
not really device nodes, but perhaps that doesn't matter. So my pref
would be something in /dev/cgroups or /sys/cgroups

I also think 'cgroups' is a better name than 'containers', since 
'containers' is refering to just one specific use case.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: cgroup mount point

[Thadeu Lima de Souza Cascardo]

[-- Attachment #1.1: Type: text/plain, Size: 3101 bytes --]

On Tue, Feb 03, 2009 at 10:24:16AM +0000, Daniel P. Berrange wrote:
> On Mon, Feb 02, 2009 at 07:41:53PM -0200, Thadeu Lima de Souza Cascardo wrote:
> > From what I've seen, most of them are in the same phases as Debian, or,
> > perhaps, behind. Fedora seems to plan that for Fedora 11, and they have
> > some support in libvirt.
> 
> libvirt is not going to impose any policy for mount points, nor mount
> anything itself. When we use cgroups, libvirt just looks up the mount
> table to find out where the admin or distro has put the mount points
> for each cgroups controller.
>
> I've also not done anything in default Fedora install to automatically
> setup cgroups, since doing that hits the hard-to-answer question of
> whether to mount all controllers in one, or a separate mount per
> controller, or a hybrid.

Sorry. I didn't mean to imply that libvirt or Fedora did anything in
respect to the mountpoint themselves. But that they are supporting or
planning to support cgroups. And I think that one time we will need to
sort the problem of the mountpoint, either let the applications mount it
(in this case, libvirt) or the system do it (Fedora install, Debian
initscripts, et al).

I have some experience with lxc tools from http://lxc.sf.net/ and these
tools also look up the mountpoint at /proc/mounts. So it is up to the
system or the user to mount it.

> > So, we have some more options now: /cgroups, /containers, /dev/cpuset,
> > /dev/cpuctl, /opt/cgroup, /opt/cpuset.
> 
> Putting new mount points in / is not really acceptable, so that rules
> out the first two. /opt is just totally wrong, since that is intended
> for add on software packages. /dev/ feels a little odd, since it is
> not really device nodes, but perhaps that doesn't matter. So my pref
> would be something in /dev/cgroups or /sys/cgroups

My suggestions were /proc/cgroup, /sys/cgroup, /cgroup or /dev/cgroup. I
sent the problems with the former two, and the rationale for the latter
two in a previous message.

I agree that /opt/ is not the place for it (and that's the one I called
'funny'). I've head some people telling that /dev/ is for devices, but I
can't see a problem (/dev/log is a socket and it is there, the FHS
refers to special files).

/proc/ and /sys/ are two good options if the kernel does not put anything
else there. /proc/cgroups already exist, for example.

Could you please give your rationale why / is not really acceptable?

> I also think 'cgroups' is a better name than 'containers', since 
> 'containers' is refering to just one specific use case.

Agreed on this one, although I still prefer the singular (it is also the
name of the filesystem type).

> Regards,
> Daniel
> -- 
> |: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
> |: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Regards,
Cascardo.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Re: cgroup mount point

[Gabor Gombas]

On Tue, Feb 03, 2009 at 10:24:16AM +0000, Daniel P. Berrange wrote:

> Putting new mount points in / is not really acceptable, so that rules
> out the first two. /opt is just totally wrong, since that is intended
> for add on software packages. /dev/ feels a little odd, since it is
> not really device nodes, but perhaps that doesn't matter. So my pref
> would be something in /dev/cgroups or /sys/cgroups

How about /var/lib/cgroup? There's already precedent
(/var/lib/nfs/rpc_pipefs) of mounting virtual file systems under
/var/lib.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

Re: cgroup mount point

[Gabor Gombas]

On Tue, Feb 03, 2009 at 10:24:16AM +0000, Daniel P. Berrange wrote:

> Putting new mount points in / is not really acceptable, so that rules
> out the first two. /opt is just totally wrong, since that is intended
> for add on software packages. /dev/ feels a little odd, since it is
> not really device nodes, but perhaps that doesn't matter. So my pref
> would be something in /dev/cgroups or /sys/cgroups

How about /var/lib/cgroup? There's already precedent
(/var/lib/nfs/rpc_pipefs) of mounting virtual file systems under
/var/lib.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

Re: cgroup mount point

[Bill Nottingham]

Gabor Gombas (gombasg-SuEj7oiQppWHXe+LvDLADg@public.gmane.org) said: 
> On Tue, Feb 03, 2009 at 10:24:16AM +0000, Daniel P. Berrange wrote:
> 
> > Putting new mount points in / is not really acceptable, so that rules
> > out the first two. /opt is just totally wrong, since that is intended
> > for add on software packages. /dev/ feels a little odd, since it is
> > not really device nodes, but perhaps that doesn't matter. So my pref
> > would be something in /dev/cgroups or /sys/cgroups
> 
> How about /var/lib/cgroup? There's already precedent
> (/var/lib/nfs/rpc_pipefs) of mounting virtual file systems under
> /var/lib.

Depending on when you need the cgroup filesystem to setup your
containers, /var may not be there.

Bill

Re: cgroup mount point

[Bill Nottingham]

Gabor Gombas (gombasg@sztaki.hu) said: 
> On Tue, Feb 03, 2009 at 10:24:16AM +0000, Daniel P. Berrange wrote:
> 
> > Putting new mount points in / is not really acceptable, so that rules
> > out the first two. /opt is just totally wrong, since that is intended
> > for add on software packages. /dev/ feels a little odd, since it is
> > not really device nodes, but perhaps that doesn't matter. So my pref
> > would be something in /dev/cgroups or /sys/cgroups
> 
> How about /var/lib/cgroup? There's already precedent
> (/var/lib/nfs/rpc_pipefs) of mounting virtual file systems under
> /var/lib.

Depending on when you need the cgroup filesystem to setup your
containers, /var may not be there.

Bill

Re: cgroup mount point

[Thadeu Lima de Souza Cascardo]

[-- Attachment #1: Type: text/plain, Size: 3101 bytes --]

On Tue, Feb 03, 2009 at 10:24:16AM +0000, Daniel P. Berrange wrote:
> On Mon, Feb 02, 2009 at 07:41:53PM -0200, Thadeu Lima de Souza Cascardo wrote:
> > From what I've seen, most of them are in the same phases as Debian, or,
> > perhaps, behind. Fedora seems to plan that for Fedora 11, and they have
> > some support in libvirt.
> 
> libvirt is not going to impose any policy for mount points, nor mount
> anything itself. When we use cgroups, libvirt just looks up the mount
> table to find out where the admin or distro has put the mount points
> for each cgroups controller.
>
> I've also not done anything in default Fedora install to automatically
> setup cgroups, since doing that hits the hard-to-answer question of
> whether to mount all controllers in one, or a separate mount per
> controller, or a hybrid.

Sorry. I didn't mean to imply that libvirt or Fedora did anything in
respect to the mountpoint themselves. But that they are supporting or
planning to support cgroups. And I think that one time we will need to
sort the problem of the mountpoint, either let the applications mount it
(in this case, libvirt) or the system do it (Fedora install, Debian
initscripts, et al).

I have some experience with lxc tools from http://lxc.sf.net/ and these
tools also look up the mountpoint at /proc/mounts. So it is up to the
system or the user to mount it.

> > So, we have some more options now: /cgroups, /containers, /dev/cpuset,
> > /dev/cpuctl, /opt/cgroup, /opt/cpuset.
> 
> Putting new mount points in / is not really acceptable, so that rules
> out the first two. /opt is just totally wrong, since that is intended
> for add on software packages. /dev/ feels a little odd, since it is
> not really device nodes, but perhaps that doesn't matter. So my pref
> would be something in /dev/cgroups or /sys/cgroups

My suggestions were /proc/cgroup, /sys/cgroup, /cgroup or /dev/cgroup. I
sent the problems with the former two, and the rationale for the latter
two in a previous message.

I agree that /opt/ is not the place for it (and that's the one I called
'funny'). I've head some people telling that /dev/ is for devices, but I
can't see a problem (/dev/log is a socket and it is there, the FHS
refers to special files).

/proc/ and /sys/ are two good options if the kernel does not put anything
else there. /proc/cgroups already exist, for example.

Could you please give your rationale why / is not really acceptable?

> I also think 'cgroups' is a better name than 'containers', since 
> 'containers' is refering to just one specific use case.

Agreed on this one, although I still prefer the singular (it is also the
name of the filesystem type).

> Regards,
> Daniel
> -- 
> |: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
> |: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Regards,
Cascardo.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: cgroup mount point

[Daniel P. Berrange]

On Tue, Feb 03, 2009 at 10:30:28AM -0200, Thadeu Lima de Souza Cascardo wrote:
> Sorry. I didn't mean to imply that libvirt or Fedora did anything in
> respect to the mountpoint themselves. But that they are supporting or
> planning to support cgroups. And I think that one time we will need to
> sort the problem of the mountpoint, either let the applications mount it
> (in this case, libvirt) or the system do it (Fedora install, Debian
> initscripts, et al).
>
> I have some experience with lxc tools from http://lxc.sf.net/ and these
> tools also look up the mountpoint at /proc/mounts. So it is up to the
> system or the user to mount it.

That's good. We settled on letting mount points be OS / admin defined
in libvirt, because we felt libvirt shouldn't try to impose a mount
policy on a resource that will have many users & we are able to work
with whatever mount hierarchy the admin / OS decided to setup.

> > Putting new mount points in / is not really acceptable, so that rules
> > out the first two. /opt is just totally wrong, since that is intended
> > for add on software packages. /dev/ feels a little odd, since it is
> > not really device nodes, but perhaps that doesn't matter. So my pref
> > would be something in /dev/cgroups or /sys/cgroups
> 
> My suggestions were /proc/cgroup, /sys/cgroup, /cgroup or /dev/cgroup. I
> sent the problems with the former two, and the rationale for the latter
> two in a previous message.
> 
> I agree that /opt/ is not the place for it (and that's the one I called
> 'funny'). I've head some people telling that /dev/ is for devices, but I
> can't see a problem (/dev/log is a socket and it is there, the FHS
> refers to special files).
> 
> /proc/ and /sys/ are two good options if the kernel does not put anything
> else there. /proc/cgroups already exist, for example.
> 
> Could you please give your rationale why / is not really acceptable?
 
Just a general preference is to not continually add more ad-hoc top 
level directories to /, when there are other places in the filesystem
hierarchy that are available, such as /sys or /proc. 

> > I also think 'cgroups' is a better name than 'containers', since 
> > 'containers' is refering to just one specific use case.
> 
> Agreed on this one, although I still prefer the singular (it is also the
> name of the filesystem type).

Either singular / plural sounds fine to me

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: cgroup mount point

[Daniel P. Berrange]

On Tue, Feb 03, 2009 at 10:30:28AM -0200, Thadeu Lima de Souza Cascardo wrote:
> Sorry. I didn't mean to imply that libvirt or Fedora did anything in
> respect to the mountpoint themselves. But that they are supporting or
> planning to support cgroups. And I think that one time we will need to
> sort the problem of the mountpoint, either let the applications mount it
> (in this case, libvirt) or the system do it (Fedora install, Debian
> initscripts, et al).
>
> I have some experience with lxc tools from http://lxc.sf.net/ and these
> tools also look up the mountpoint at /proc/mounts. So it is up to the
> system or the user to mount it.

That's good. We settled on letting mount points be OS / admin defined
in libvirt, because we felt libvirt shouldn't try to impose a mount
policy on a resource that will have many users & we are able to work
with whatever mount hierarchy the admin / OS decided to setup.

> > Putting new mount points in / is not really acceptable, so that rules
> > out the first two. /opt is just totally wrong, since that is intended
> > for add on software packages. /dev/ feels a little odd, since it is
> > not really device nodes, but perhaps that doesn't matter. So my pref
> > would be something in /dev/cgroups or /sys/cgroups
> 
> My suggestions were /proc/cgroup, /sys/cgroup, /cgroup or /dev/cgroup. I
> sent the problems with the former two, and the rationale for the latter
> two in a previous message.
> 
> I agree that /opt/ is not the place for it (and that's the one I called
> 'funny'). I've head some people telling that /dev/ is for devices, but I
> can't see a problem (/dev/log is a socket and it is there, the FHS
> refers to special files).
> 
> /proc/ and /sys/ are two good options if the kernel does not put anything
> else there. /proc/cgroups already exist, for example.
> 
> Could you please give your rationale why / is not really acceptable?
 
Just a general preference is to not continually add more ad-hoc top 
level directories to /, when there are other places in the filesystem
hierarchy that are available, such as /sys or /proc. 

> > I also think 'cgroups' is a better name than 'containers', since 
> > 'containers' is refering to just one specific use case.
> 
> Agreed on this one, although I still prefer the singular (it is also the
> name of the filesystem type).

Either singular / plural sounds fine to me

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: cgroup mount point

[Thadeu Lima de Souza Cascardo]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On Tue, Feb 03, 2009 at 11:44:00PM +1100, Ben Finney wrote:
> "Daniel P. Berrange" <berrange@redhat.com> writes:
> 
> > On Mon, Feb 02, 2009 at 07:41:53PM -0200, Thadeu Lima de Souza Cascardo wrote:
> > > So, we have some more options now: /cgroups, /containers,
> > > /dev/cpuset, /dev/cpuctl, /opt/cgroup, /opt/cpuset.
> > 
> > Putting new mount points in / is not really acceptable, so that rules
> > out the first two. /opt is just totally wrong, since that is intended
> > for add on software packages. /dev/ feels a little odd, since it is
> > not really device nodes
> 
> I agree with all that Thadeu Lima says here. I would add that cgroups
> are nothing to do with device nodes, so definitely don't belong in
> ‘/dev/’ either.

The message you quoted is from Daniel Berrange, not me. Could you also
tell your rationale for not agreeing with /?

Regards,
Cascardo.

> Since they're a filesystem mapping “for browsing and manipulation
> from user space” of a kernel facility, I think ‘/sys/cgroups/’ is
> appropriate.
> 
> -- 
>  \     “It's my belief we developed language because of our deep inner |
>   `\                  need to complain.” —Jane Wagner, via Lily Tomlin |
> _o__)                                                                  |
> Ben Finney

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: cgroup mount point

[Ben Finney]

Thadeu Lima de Souza Cascardo <cascardo@minaslivre.org> writes:

> The message you quoted is from Daniel Berrange, not me.

You're right. I should have read more carefully.

> Could you also tell your rationale for not agreeing with /?

The bar for adding new required entries to the root directory is now
very high. The facility being discussed is far too specific to need a
top-level entry, especially when better alternatives have already been
suggested that fit it into the existing, more meaningful, directories.

-- 
 \       “The optimist thinks this is the best of all possible worlds. |
  `\           The pessimist fears it is true.” —J. Robert Oppenheimer |
_o__)                                                                  |
Ben Finney

Re: cgroup mount point

[Thadeu Lima de Souza Cascardo]

[-- Attachment #1.1: Type: text/plain, Size: 1350 bytes --]

On Tue, Feb 03, 2009 at 11:44:00PM +1100, Ben Finney wrote:
> "Daniel P. Berrange" <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> 
> > On Mon, Feb 02, 2009 at 07:41:53PM -0200, Thadeu Lima de Souza Cascardo wrote:
> > > So, we have some more options now: /cgroups, /containers,
> > > /dev/cpuset, /dev/cpuctl, /opt/cgroup, /opt/cpuset.
> > 
> > Putting new mount points in / is not really acceptable, so that rules
> > out the first two. /opt is just totally wrong, since that is intended
> > for add on software packages. /dev/ feels a little odd, since it is
> > not really device nodes
> 
> I agree with all that Thadeu Lima says here. I would add that cgroups
> are nothing to do with device nodes, so definitely don't belong in
> ‘/dev/’ either.

The message you quoted is from Daniel Berrange, not me. Could you also
tell your rationale for not agreeing with /?

Regards,
Cascardo.

> Since they're a filesystem mapping “for browsing and manipulation
> from user space” of a kernel facility, I think ‘/sys/cgroups/’ is
> appropriate.
> 
> -- 
>  \     “It's my belief we developed language because of our deep inner |
>   `\                  need to complain.” —Jane Wagner, via Lily Tomlin |
> _o__)                                                                  |
> Ben Finney

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[-- Attachment #2: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Re: cgroup mount point

[Gustavo Noronha]

On Tue, 2009-02-03 at 23:44 +1100, Ben Finney wrote:
> I agree with all that Thadeu Lima says here. I would add that cgroups
> are nothing to do with device nodes, so definitely don't belong in
> ‘/dev/’ either.
> 
> Since they're a filesystem mapping “for browsing and manipulation
> from user space” of a kernel facility, I think ‘/sys/cgroups/’ is
> appropriate.

I agree with this point of view. I believe /sys/cgroups is the way to
go. Now, of course this has the drawback of shadowing something future
versions of Linux would make available at that same path, but I am
pretty sure they would be careful not to do that after distributions
have settled on a standard path.

See you,

-- 
Gustavo Noronha <kov@debian.org>
Debian Project

Re: cgroup mount point

[Paul Menage]

On Tue, Feb 3, 2009 at 6:38 AM, Gustavo Noronha <kov@debian.org> wrote:
> On Tue, 2009-02-03 at 23:44 +1100, Ben Finney wrote:
>> I agree with all that Thadeu Lima says here. I would add that cgroups
>> are nothing to do with device nodes, so definitely don't belong in
>> '/dev/' either.
>>
>> Since they're a filesystem mapping "for browsing and manipulation
>> from user space" of a kernel facility, I think '/sys/cgroups/' is
>> appropriate.
>
> I agree with this point of view. I believe /sys/cgroups is the way to
> go. Now, of course this has the drawback of shadowing something future
> versions of Linux would make available at that same path, but I am
> pretty sure they would be careful not to do that after distributions
> have settled on a standard path.

Having one virtual filesystem mounted on top of another virtual
filesystem seems like a recipe for problems. /dev/cgroup or
/dev/cgroup/<hierarchy_name> sounds more reasonable to me (although if
anyone is still using devfs that would suffer from the same drawbacks)

Paul

Re: cgroup mount point

[Mike Hommey]

On Tue, Feb 03, 2009 at 08:55:34AM -0800, Paul Menage wrote:
> On Tue, Feb 3, 2009 at 6:38 AM, Gustavo Noronha <kov@debian.org> wrote:
> > On Tue, 2009-02-03 at 23:44 +1100, Ben Finney wrote:
> >> I agree with all that Thadeu Lima says here. I would add that cgroups
> >> are nothing to do with device nodes, so definitely don't belong in
> >> '/dev/' either.
> >>
> >> Since they're a filesystem mapping "for browsing and manipulation
> >> from user space" of a kernel facility, I think '/sys/cgroups/' is
> >> appropriate.
> >
> > I agree with this point of view. I believe /sys/cgroups is the way to
> > go. Now, of course this has the drawback of shadowing something future
> > versions of Linux would make available at that same path, but I am
> > pretty sure they would be careful not to do that after distributions
> > have settled on a standard path.
> 
> Having one virtual filesystem mounted on top of another virtual
> filesystem seems like a recipe for problems.

Like with /sys/fs/fuse/connections ? Come on, there is no problem with a
virtual filesystem mounted on top of another.

Mike

Re: cgroup mount point

[sean finney]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

On Tue, Feb 03, 2009 at 07:49:15PM +0100, Mike Hommey wrote:
> > Having one virtual filesystem mounted on top of another virtual
> > filesystem seems like a recipe for problems.
> 
> Like with /sys/fs/fuse/connections ? Come on, there is no problem with a
> virtual filesystem mounted on top of another.

or /proc/bus/usb or /dev/shm or /dev/pts... :)


	sean

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: cgroup mount point

[Paul Menage]

On Tue, Feb 3, 2009 at 10:51 AM, sean finney <seanius@seanius.net> wrote:
> On Tue, Feb 03, 2009 at 07:49:15PM +0100, Mike Hommey wrote:
>> > Having one virtual filesystem mounted on top of another virtual
>> > filesystem seems like a recipe for problems.
>>
>> Like with /sys/fs/fuse/connections ? Come on, there is no problem with a
>> virtual filesystem mounted on top of another.
>
> or /proc/bus/usb or /dev/shm or /dev/pts... :)
>

/dev is a bit different though - even if it's mounted as a udev fs,
you can create a new directory in there to act as a mount point.

Cgroups supports multiple hierarchies on different mount points.

So if you have two cgroups hierarchies - say one for CPU/network and
one for memory isolation, you could create /dev/cgroup/cpunet and
/dev/cgroup/memory and mount the two hierarchies. But sysfs doesn't
allow you to create new subdirectories to act as mountpoints. If we
can have a /sys/cgroups directory which allows you to create arbitrary
subdirs to act as mountpoints, that could be OK.

Or just fake it by mounting a tmpfs on /sys/cgroups and then create
mount points in there, but that seems like a bit of a hack.

Paul

Re: cgroup mount point

[Harald Braumann]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

On Tue, 3 Feb 2009 11:14:03 -0800
Paul Menage <menage@google.com> wrote:

> On Tue, Feb 3, 2009 at 10:51 AM, sean finney <seanius@seanius.net>
> wrote:
> > or /proc/bus/usb or /dev/shm or /dev/pts... :)
> >
> 
> /dev is a bit different though - even if it's mounted as a udev fs,
> you can create a new directory in there to act as a mount point.

So, what's the problem with /dev/cgroups then? If shm/ and pts/
are allowed under /dev, wouldn't it be discriminating against
cgroups/, to not allow it there?

Cheers,
harry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: cgroup mount point

[Paul Menage]

On Tue, Feb 3, 2009 at 3:38 PM, Harald Braumann <harry@unheit.net> wrote:
>
> So, what's the problem with /dev/cgroups then? If shm/ and pts/
> are allowed under /dev, wouldn't it be discriminating against
> cgroups/, to not allow it there?

Right, that's what I proposed a couple of emails earlier in this thread.

Paul

Re: cgroup mount point

[Harald Braumann]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On Tue, 3 Feb 2009 15:40:39 -0800
Paul Menage <menage@google.com> wrote:

> On Tue, Feb 3, 2009 at 3:38 PM, Harald Braumann <harry@unheit.net>
> wrote:
> >
> > So, what's the problem with /dev/cgroups then? If shm/ and pts/
> > are allowed under /dev, wouldn't it be discriminating against
> > cgroups/, to not allow it there?
> 
> Right, that's what I proposed a couple of emails earlier in this
> thread.

Sorry, I didn't mean to imply that you'd be against it, on the contrary,
I took your explanation as another argument for using /dev and
against /sys (/cgroups should not even be considered, IMHO). 

The question was targeted at those, who oppose it.

Cheers,
harry


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: cgroup mount point

[Josselin Mouette]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

Le mercredi 04 février 2009 à 00:38 +0100, Harald Braumann a écrit :
> So, what's the problem with /dev/cgroups then? If shm/ and pts/
> are allowed under /dev, wouldn't it be discriminating against
> cgroups/, to not allow it there?

/dev/pts contains device entries, so it sounds right to put it in /dev.
Similarly if the cgroups FS provides facilities to control some system
settings, it clearly belongs in /sys.

(/dev/shm is another story, and if you asked me, I’d have put it
in /lib/shm instead, but it’s a bit late to change it.)

-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: cgroup mount point

[José Luis Tallón]

Harald Braumann wrote:
> On Tue, 3 Feb 2009 11:14:03 -0800
> Paul Menage <menage@google.com> wrote:
>
>   
>> On Tue, Feb 3, 2009 at 10:51 AM, sean finney <seanius@seanius.net>
>> wrote:
>>     
>>> or /proc/bus/usb or /dev/shm or /dev/pts... :)
>>>
>>>       
>> /dev is a bit different though - even if it's mounted as a udev fs,
>> you can create a new directory in there to act as a mount point.
>>     
>
> So, what's the problem with /dev/cgroups then? If shm/ and pts/
> are allowed under /dev, wouldn't it be discriminating against
> cgroups/, to not allow it there?
>   
/dev/pts refers to the virtual pseudo-tty subsystem
    i.e. virtual pseudo-tty devices

/dev/shm refers to the "shared memory" device
    (ok, this is a bit forced)

/dev/log refers to the "log" device
    it could perfectly well be just a file. The fact that it is actually
a socket (more like a pipe to the logging daemon) does not hinder its
equivalence to a logfile.

whereas I can't fathom why a cgroup "feels" like a /device/.

I admit not being an expert in virtualization abstraction (I do run a
significant number of virtual machines, tough), but in fact /sys seems
to be a much better place for it. Please feel free to argue against if
my proposal does not in fact make sense.
While it does indeed feel "hackish", mounting a tmpfs on /sys/cgroups
and then creating as many subdirs as/if necessary is indeed achievable,
practical and flexible.

/proc might be useable though, but it has historically been associated
with "processes" and the information related to them. And yes, that
means that /proc/cpuinfo, /proc/meminfo, and /proc/bus would actually be
out of place there... but keeping backwards compatibility and not
surprising users is most important.



IMHO, other mount points (/var/run/cgroups maybe?) might make sense too.
However the fact that the most common use of cgroup is to split the
system into virtual "partitions" in some way suggests it belongs in /sys.


In any case, I want to show my appreciation and gratitude to all kernel
hackers out there. You're doing a great job, people.


Regards,

    J.L.

Re: cgroup mount point

[Harald Braumann]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

On Thu, 05 Feb 2009 22:19:37 +0100
José Luis Tallón <jltallon@adv-solutions.net> wrote:
> [...]
> whereas I can't fathom why a cgroup "feels" like a /device/.
> 
> I admit not being an expert in virtualization abstraction (I do run a
> significant number of virtual machines, tough), but in fact /sys seems
> to be a much better place for it. Please feel free to argue against if
> my proposal does not in fact make sense.

Agreed. Semantically /sys is probably the place for cgroups. 

> While it does indeed feel "hackish", mounting a tmpfs on /sys/cgroups
> and then creating as many subdirs as/if necessary is indeed
> achievable, practical and flexible.

Yes, folks have brought forth this technical difficulty and that's why
I initially thought /dev to be a better place.

For me, either would be OK. I don't care that much as long as it's not
mounted in root.

> /proc might be useable though, but it has historically been associated
> with "processes" and the information related to them. And yes, that
> means that /proc/cpuinfo, /proc/meminfo, and /proc/bus would actually
> be out of place there... but keeping backwards compatibility and not
> surprising users is most important.

Agreed. I think the trend is to remove things not related to processes
from /proc. Of course not everything can be removed immediately, but at
least no new things should be added.

Cheers,
harry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]