From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
containers@lists.linux-foundation.org,
lsf-pc@lists.linux-foundation.org
Subject: Re: [Lsf-pc] [LSF/MM ATTEND] FS jitter testing, network caching, Lustre, cluster filesystems.
Date: Tue, 17 Jan 2017 06:26:07 -0800 [thread overview]
Message-ID: <1484663167.2433.8.camel@HansenPartnership.com> (raw)
In-Reply-To: <AE738992-D640-48B1-B7C3-E4E798504F7A@linuxhacker.ru>
On Tue, 2017-01-17 at 02:00 -0500, Oleg Drokin wrote:
> On Jan 16, 2017, at 3:58 PM, James Bottomley wrote:
>
> > On Mon, 2017-01-16 at 13:39 -0500, Oleg Drokin wrote:
> > > On Jan 16, 2017, at 1:21 PM, James Bottomley wrote:
> > >
> > > > On Mon, 2017-01-16 at 13:02 -0500, Oleg Drokin wrote:
> > > > > On Jan 16, 2017, at 12:32 PM, James Bottomley wrote:
> > > > >
> > > > > > On Sun, 2017-01-15 at 18:38 -0500, Oleg Drokin wrote:
> > > > > > > A container support from filesystems is also very
> > > > > > > relevant to us since Lustre is used more and more in
> > > > > > > such settings.
> > > > > >
> > > > > > I've added the containers ML to the cc just in case. Can
> > > > > > you add more colour to this, please? What container
> > > > > > support for filesystems do you think we need beyond the
> > > > > > user namespace in the superblock?
> > > > >
> > > > > Namespace access is necessary, we might need it before the
> > > > > superblock is there too (say during mount we might need
> > > > > kerberos credentials fetched to properly authenticate this
> > > > > mount instance to the server).
> > > >
> > > > The superblock namespace is mostly for uid/gid changes across
> > > > the kernel <-> filesystem boundary.
> > >
> > > That's on the kernel<->filesystem, but inside of the FS there
> > > might be other considerations that you might want to attach
> > > there. Say when you are encrypting the traffic to the server you
> > > want to use the right keys.
> >
> > So this is the keyring namespace? It was mentioned at KS, but, as
> > far as I can tell, not discussed in the Containers MC that
> > followed, so I've no idea what the status is.
>
> Could be keyring or other mechanisms.
OK, you need to agree on the mechanism first, then we can discuss if it
needs OS virtualization. A large number of mechanisms in the kernel
actually don't (because the current OS protections are strong enough)
like file descriptors. After you understand the mechanism there are
usually four main ways to do OS virtualization:
1. Do nothing becuase the object doesn't need it (fd)
2. Label Namespace because it needs isolation (network)
3. add to user namespace because you need privileged access (setns
call)
4. add to cgroup because the resource needs to be accounted (mem)
But before we get into that we need to know the properties of the
mechanism.
James
next prev parent reply other threads:[~2017-01-17 14:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-15 23:38 [LSF/MM ATTEND] FS jitter testing, network caching, Lustre, cluster filesystems Oleg Drokin
2017-01-16 17:17 ` J. Bruce Fields
2017-01-16 17:23 ` Jeffrey Altman
2017-01-16 17:42 ` Chuck Lever
2017-01-16 17:46 ` James Bottomley
2017-01-16 20:39 ` Authentication Contexts for network file systems and Containers was " Jeffrey Altman
2017-01-16 21:03 ` [Lsf-pc] " James Bottomley
2017-01-17 16:29 ` Jeffrey Altman
2017-01-17 16:34 ` Trond Myklebust
2017-01-17 17:10 ` Jeffrey Altman
2017-01-16 17:32 ` [Lsf-pc] " James Bottomley
2017-01-16 18:02 ` Oleg Drokin
2017-01-16 18:21 ` James Bottomley
2017-01-16 18:39 ` Oleg Drokin
2017-01-16 20:58 ` James Bottomley
2017-01-17 7:00 ` Oleg Drokin
2017-01-17 14:26 ` James Bottomley [this message]
2017-01-17 17:41 ` Oleg Drokin
2017-01-17 14:56 ` James Bottomley
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=1484663167.2433.8.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=containers@lists.linux-foundation.org \
--cc=green@linuxhacker.ru \
--cc=linux-fsdevel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).