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:
> what about alternative solutions, like using pivot_root
I think that pivot_root(2) is a poor solution as you will run into the
* 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
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