About this list Date view Thread view Subject view Author view Attachment view

From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Thu 04 Nov 2004 - 14:00:30 GMT

herbert_at_13thfloor.at (Herbert Poetzl) writes:

>> Thoughts/comments
> what about alternative solutions, like using pivot_root

I think that pivot_root(2) is a poor solution as you will run into the
following problems:

* who will unmount the old filesystem? You will need something in the
  hostile vserver-root doing this...

* output/errormessages of the startup-sequence will be impossible, as
  you will have to remove any references to the old /dev/pts/*, logfiles
  or /dev/null.

Therefore, unmounting of the old '/' will be impossible for vserver

'mount --rbind /vservers/... /' is a better way: it does not make the
old filesystem visible in the vserver (with pivot_root, it would be
somewhere in the vserver) so the first problem disappears.

> or having tagged mounts (i.e. mounts accessible for or visible to
> processes which have a special flag set)
> I guess we should move away from what we have now, get some distance,
> and think about what we want to have in let's say half a year (or
> maybe a year) then start to work in that direction ...

Defining a 'vc_merge_namespace(xid_t)' operation (putting the
vserver-mounts behind the current ones) would be a solution, but the
exact semantic is complicated. You will have to make sure that this
syscall happens in a new namespace; I do not know if it is possible that
this syscall creates the new namespace itself (current namespace
creation is coupled with a process creation). Perhaps,
'vc_merge_namespace()' could do an implicit 'clone(..., CLONE_NEWNS)'?

Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Thu 04 Nov 2004 - 14:00:50 GMT by hypermail 2.1.3