On Tue, Jan 17, 2012 at 18:53, Tejun Heo <tj@xxxxxxxxxx> wrote: >> > The key idea is that this would allow attaching runtime meta information >> > to cgroups and everything they model (services, apps, vms), that doesn't >> > need any complex userspace infrastructure, has good access control >> > (i.e. because the file system enforces that anyway, and there's the >> > "trusted." xattr namespace), notifications (inotify), and can easily be >> > shared among applications. > Ummm... I don't feel too good about this. Why can't those extra > information be kept somewhere else? Overloading cgroupfs as storage > for essentially opaque userland information doesn't seem like a good > idea to me. A bit of the background: The /sys/fs/cgroup/systemd/ hierarchy represents something like a first class kernel-related system object, which we call an 'application' or 'service' in userspace. Every 'service' or 'application' has zero, one or many processes, and has some high-level metadata attached. The general idea, not specifcally related to cgroups, is to try as hard as possible to stick metadata about objects to the objects themselves. It's a bit like the difference of lock files vs. locks attached to a process. In the later case, if the process dies, the lock is automatically cleaned up, in the former, we have a stale file. The idea with the cgroup fs xattrs was to be able to attach some general useful attributes to the 'service container' itself, instead of keeping them in the memory of the managing process or store them on disk which can get out-of-sync much easier. Kay -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
