Re: EXCHANGE_ID with same network address but different server owner

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2017-05-18 at 11:28 -0400, bfields@xxxxxxxxxxxx wrote:
> On Thu, May 18, 2017 at 03:17:11PM +0000, Trond Myklebust wrote:
> > For the case that Stefan is discussing (kvm) it would literally be
> > a
> > single process that is being migrated. For lxc and
> > docker/kubernetes-
> > style containers, it would be a collection of processes.
> > 
> > The mountpoints used by these containers are often owned by the
> > host;
> > they are typically set up before starting the containerised
> > processes.
> > Furthermore, there is typically no "start container" system call
> > that
> > we can use to identify which set of processes (or cgroups) are
> > containerised, and should share a clientid.
> 
> Is that such a hard problem?
> 

Err, yes... isn't it? How do I identify a container and know where to
set the lease boundary?

Bear in mind that the definition of "container" is non-existent beyond
the obvious "a loose collection of processes". It varies from the
docker/lxc/virtuozzo style container, which uses namespaces to bound
the processes, to the Google type of "container" that is actually just
a set of cgroups and to the kvm/qemu single process.

> In any case, from the protocol point of view these all sound like
> client
> implementation details.

If you are seeing an obvious architecture for the client, then please
share...

> The only problem I see with multiple client ID's is that you'd like
> to
> keep their delegations from conflicting with each other so they can
> share cache.
> 
> But, maybe I'm missing something else.

Having to an EXCHANGE_ID + CREATE_SESSION on every call to
fork()/clone() and a DESTROY_SESSION/DESTROY_EXCHANGEID in each process
destructor? Lease renewal pings from 1000 processes running on 1000
clients?

This is what I mean about container boundaries. If they aren't well
defined, then we're down to doing precisely the above.

-- 
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@xxxxxxxxxxxxxxx
��.n��������+%������w��{.n�����{��w���jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux