From: Lennart Poettering <mzxreary@0pointer.de>
To: Tejun Heo <tj@kernel.org>
Cc: Kay Sievers <kay.sievers@vrfy.org>,
Li Zefan <lizf@cn.fujitsu.com>,
LKML <linux-kernel@vger.kernel.org>,
Cgroups <cgroups@vger.kernel.org>
Subject: Re: [PATCH 2/2] cgroup: add xattr support
Date: Sat, 21 Jan 2012 04:02:04 +0100 [thread overview]
Message-ID: <20120121030204.GE2100@tango.0pointer.de> (raw)
In-Reply-To: <20120119024021.GI21533@google.com>
On Wed, 18.01.12 18:40, Tejun Heo (tj@kernel.org) wrote:
>
> On Wed, Jan 18, 2012 at 06:20:05PM -0800, Tejun Heo wrote:
> > Hello, Lennart, Li.
> >
> > Two things.
> >
> > * Probably I'm missing something but isn't the systemd cgroup
> > hierarchy already managed by systemd? If so, I don't see how
> > managing tmpfs on the side would noticeably make things more
> > fragile. It would take a bit more care after, for example, restart
> > but it shouldn't be too complex, no?
> >
> > * FS attributes already being used for userland information seems like
> > a good argument, but we shouldn't add separate specialized xattr
> > implementation to different pseudo filesystems. For it to be
> > acceptable, it should be a libfs thing easily applicable to any
> > pseudo FS and definitely shouldn't be using kmem for storage.
>
> Also note that tmpfs also implies size limit. We definitely need some
> form of control over the amount of memory xattr may consume.
Good point. But then again we don't even have anything resembling for
tmpfs either, where it would be much more important... :-(
Given that cgroupfs is probably mostly read-only for normal users, the
requirement for quotas on it is probably much less important than for tmpfs
though.
Lennart
--
Lennart Poettering - Red Hat, Inc.
WARNING: multiple messages have this Message-ID (diff)
From: Lennart Poettering <mzxreary-uLTowLwuiw4b1SvskN2V4Q@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>,
Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 2/2] cgroup: add xattr support
Date: Sat, 21 Jan 2012 04:02:04 +0100 [thread overview]
Message-ID: <20120121030204.GE2100@tango.0pointer.de> (raw)
In-Reply-To: <20120119024021.GI21533-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Wed, 18.01.12 18:40, Tejun Heo (tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org) wrote:
>
> On Wed, Jan 18, 2012 at 06:20:05PM -0800, Tejun Heo wrote:
> > Hello, Lennart, Li.
> >
> > Two things.
> >
> > * Probably I'm missing something but isn't the systemd cgroup
> > hierarchy already managed by systemd? If so, I don't see how
> > managing tmpfs on the side would noticeably make things more
> > fragile. It would take a bit more care after, for example, restart
> > but it shouldn't be too complex, no?
> >
> > * FS attributes already being used for userland information seems like
> > a good argument, but we shouldn't add separate specialized xattr
> > implementation to different pseudo filesystems. For it to be
> > acceptable, it should be a libfs thing easily applicable to any
> > pseudo FS and definitely shouldn't be using kmem for storage.
>
> Also note that tmpfs also implies size limit. We definitely need some
> form of control over the amount of memory xattr may consume.
Good point. But then again we don't even have anything resembling for
tmpfs either, where it would be much more important... :-(
Given that cgroupfs is probably mostly read-only for normal users, the
requirement for quotas on it is probably much less important than for tmpfs
though.
Lennart
--
Lennart Poettering - Red Hat, Inc.
next prev parent reply other threads:[~2012-01-21 3:02 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-16 8:06 [PATCH 1/2] cgroup: revise how we re-populate root directory Li Zefan
2012-01-16 8:06 ` Li Zefan
2012-01-16 8:07 ` [PATCH 2/2] cgroup: add xattr support Li Zefan
2012-01-16 8:07 ` Li Zefan
2012-01-17 17:53 ` Tejun Heo
2012-01-17 17:53 ` Tejun Heo
2012-01-18 8:27 ` Li Zefan
2012-01-18 8:27 ` Li Zefan
2012-01-18 17:47 ` Tejun Heo
2012-01-18 17:47 ` Tejun Heo
2012-01-19 1:49 ` Lennart Poettering
2012-01-18 21:28 ` Kay Sievers
2012-01-18 21:28 ` Kay Sievers
2012-01-18 21:36 ` Tejun Heo
2012-01-18 21:36 ` Tejun Heo
2012-01-19 1:47 ` Lennart Poettering
2012-01-19 2:20 ` Tejun Heo
2012-01-19 2:20 ` Tejun Heo
2012-01-19 2:40 ` Tejun Heo
2012-01-19 2:40 ` Tejun Heo
2012-01-21 3:02 ` Lennart Poettering [this message]
2012-01-21 3:02 ` Lennart Poettering
2012-01-21 4:00 ` Hugh Dickins
2012-01-21 4:00 ` Hugh Dickins
2012-01-21 2:59 ` Lennart Poettering
2012-01-21 2:59 ` Lennart Poettering
2012-01-18 7:23 ` [PATCH 1/2] cgroup: revise how we re-populate root directory Sha
2012-01-18 7:23 ` Sha
2012-01-18 7:59 ` Li Zefan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120121030204.GE2100@tango.0pointer.de \
--to=mzxreary@0pointer.de \
--cc=cgroups@vger.kernel.org \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.