[PL #4425] new vserver patch changes file system
visibilitymodel
Marc E. Fiuczynski via RT
devel at planet-lab.org
Thu Feb 24 14:09:10 EST 2005
Email Recipients (see http://www.planet-lab.org/Support)
Requestor: mef at cs.princeton.edu
Ticket Ccs: llp at cs.princeton.edu, troscoe at intel-research.net
==================================================
Hi Mic,
It would certainly be a good idea to turn the vserver folks. Herbert Poetzl, the main vserver kernel person, is quite good and available for consulting. Larry and I spoke about that briefly last August.
The main thing I'd like Herbert to do is clean up vserver by porting large chunks of his code base to LSM, CKRM, and do other general clean up. His coding style is, well, organic. THe vserver code base spreads over a large number of files and sucks baseline Linux code into statically inlined functions + some vserver specific code.
We should explore this angle further.
Marc
> -----Original Message-----
> From: Mic Bowman via RT [mailto:devel at planet-lab.org]
> Sent: Thursday, February 24, 2005 1:37 PM
> To: mef at CS.Princeton.EDU
> Subject: RE: [PL #4425] new vserver patch changes file system
> visibilitymodel
>
>
> Email Recipients (see http://www.planet-lab.org/Support)
> Requestor: mef at cs.princeton.edu
> Ticket Ccs: llp at cs.princeton.edu, troscoe at intel-research.net
>
> ==================================================
>
> Good.
>
> Should we get more active in the group? It would certainly be helpful if
> we could get the vservers developers to start doing some of our work for
> us. For example... Could we turn them on to help formalize proper and
> the "out-of-band" interfaces? Are there conflicts/patches to CKRM that
> we could roll back into the vservers guys? What about disk/memory quota
> work or even the shares based scheduling. They might not do exactly what
> we want, but it would sure be nice to free up your time to work on other
> stuff...
>
> --Mic
>
>
> > -----Original Message-----
> > From: devel-community-bounces at planet-lab.org
> > [mailto:devel-community-bounces at planet-lab.org] On Behalf Of
> > Marc E. Fiuczynski via RT
> > Sent: Thursday, February 24, 2005 9:48 AM
> > Subject: RE: [PL #4425] new vserver patch changes file system
> > visibilitymodel
> >
> > Email Recipients (see http://www.planet-lab.org/Support)
> > Requestor: mef at cs.princeton.edu
> >
> >
> > ==================================================
> >
> > I've been in touch with Herbert before and will send him a
> > patch to support this functionality.
> >
> > > -----Original Message-----
> > > From: Mic Bowman via RT [mailto:devel at planet-lab.org]
> > > Sent: Thursday, February 24, 2005 11:19 AM
> > > To: mef at CS.Princeton.EDU
> > > Subject: RE: [PL #4425] new vserver patch changes file system
> > > visibility model
> > >
> > >
> > > Email Recipients (see http://www.planet-lab.org/Support)
> > > Requestor: mef at cs.princeton.edu
> > >
> > >
> > > ==================================================
> > >
> > > Are we active in the vserver community? Since we have such a
> > > dependency on them, it might be nice to see if we could "influence"
> > > some decisions like this to make it easier for us.
> > >
> > > --Mic
> > >
> > >
> > > > -----Original Message-----
> > > > From: devel-community-bounces at planet-lab.org
> > > > [mailto:devel-community-bounces at planet-lab.org] On Behalf
> > Of Marc E.
> > > > Fiuczynski via RT
> > > > Sent: Thursday, February 24, 2005 6:05 AM
> > > > Subject: [PL #4425] new vserver patch changes file system
> > visibility
> > > > model
> > > >
> > > > Email Recipients (see http://www.planet-lab.org/Support)
> > > > Requestor: mef at cs.princeton.edu
> > > >
> > > >
> > > > ==================================================
> > > >
> > > > Thu Feb 24 09:04:52 2005: Request 4425 was acted upon.
> > > > Transaction: Ticket created by mef
> > > >
> > > > Subject: new vserver patch changes file system visibility model
> > > >
> > > > This message is for tracking purposes (and association
> > between CVS
> > > > committed changes), as the reported problem has been resolved.
> > > >
> > > > The upgrade to vserver 1.9.3.17 introduced a feature to
> > hide files
> > > > created by different vservers. Presumably this permits vserver
> > > > contexts to share the same filesystem namespace without
> > being able
> > > > to properly access files created by separate contexts. I am sure
> > > > the vserver folks have a good reason for this, but it breaks our
> > > > assumption that chroot() is the primary means for filesystem
> > > > namespace isolation.
> > > >
> > > > Any way, the introduction of this new "feature" breaks the cross
> > > > mount feature that proper provides to stork et al.
> > > >
> > > > I've made the appropriate change to fs/namei.c encapsulated by
> > > > CONFIG_VSERVER_FILESHARING, to support our model in
> > addition to the
> > > > new vserver model. Note that this change is in addition to the
> > > > xid_permission cleanup suggested by Steve (see email
> > thread included
> > > > below).
> > > >
> > > > Marc
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Mark Huang [mailto:mlhuang at CS.Princeton.EDU]
> > > > > Sent: Tuesday, February 22, 2005 4:11 PM
> > > > > To: Steve Muir; mef at CS.Princeton.EDU
> > > > > Subject: Re: pl_netflow on alice
> > > > >
> > > > >
> > > > > Marc, can you take care of this?
> > > > >
> > > > > What I'm more worried about, is whether one of our patches
> > > > got dropped
> > > > > by CVS without generating a merge conflict, or whether
> > the VServer
> > > > > guys simply screwed up. I'd prefer it if it were the latter...
> > > > >
> > > > > --Mark
> > > > >
> > > > > Steve Muir wrote:
> > > > > > the appropriate patch to fs/namei.c for 2.6.10 is
> > > > probably to either
> > > > > > remove xid_permission() (and the associated call) altogether,
> > > > > or replace
> > > > > > all the code after the barrier check with a 'return 0'
> > > > > > statement, depending upon whether you want to have to perform
> > > > barrier checking
> > > > > > in generic_permission and every fs-specific
> > > > i_op->permission called
> > > > > > by permission(). personally i would keep the barrier check in
> > > > > > xid_permission() and not worry about the redundant checks
> > > > in other
> > > > > > places unless you particularly feel like tidying up.
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Steve Muir [mailto:smuir at CS.Princeton.EDU]
> > > > Sent: Tuesday, February 22, 2005 3:57 PM
> > > > To: Mark Huang
> > > > Cc: mef at CS.Princeton.EDU
> > > > Subject: Re: pl_netflow on alice
> > > >
> > > >
> > > > i believe this problem is due to one of our ad-hoc patches not
> > > > making it into the 2.6.10 kernel. try creating a file in the
> > > > pl_netflow context, then reading it from the root context
> > > > - you can't. Paul Brett hacked the vserver code eons ago
> > to ignore
> > > > the xid check when calling path_lookup, and i probably
> > ported that
> > > > hack to the original v3 kernel, i'll see if i can figure out what
> > > > needs changing.
> > > >
> > > >
> > > >
> > > > On Tue, 22 Feb 2005, Mark Huang wrote:
> > > >
> > > > > Steve Muir wrote:
> > > > >> i think i've fixed the problem, i've updated Proper on
> > > > alice, please
> > > > >> try recreating pl_netflow and checking that it works now.
> > > > >
> > > > > Nah, same problem. To try and (re)start pl_netflow, just do
> > > > >
> > > > > vserver pl_netflow exec /etc/init.d/netflow restart
> > > > >
> > > > > --Mark
> > > > >
> > > >
> > > > _______________________________________________
> > > > Devel-community mailing list
> > > > Devel-community at lists.planet-lab.org
> > > > http://lists.planet-lab.org/mailman/listinfo/devel-community
> > > >
> > >
> >
> >
> > _______________________________________________
> > Devel-community mailing list
> > Devel-community at lists.planet-lab.org
> > http://lists.planet-lab.org/mailman/listinfo/devel-community
> >
>
More information about the Devel-community
mailing list