Re: [PATCH][CFT] per-process namespaces for Linux

Alexander Viro (viro@math.psu.edu)
Sun, 25 Feb 2001 19:26:24 -0500 (EST)


On Mon, 26 Feb 2001, Werner Almesberger wrote:

> Alexander Viro wrote:
> > No. Just an overmount.
>
> Ah, too bad. Union mounts would have been really elegant (allowing the
> operation to be repeated without residues, and also allowing umounting
> of the covered FS as a sanity check). But I guess there's no way to
> implement them without performance penalty ...

There is no way to implement them without credentials' cache. Which needs
to be done for many other reasons, but that's a separate patch and
separate story. If it's done - no serious penalty involved. However,
I doubt that we want a union on / itself. /dev - sure, /bin and /lib -
maybe, but /... What for?

> > Is it worth emptying?
>
> Probably not ... the only interesting case would be if you could completely
> umount it.

What's the point in unmounting it? Let the root of the mount tree be fixed -
it actually simplifies the things big way. Not that we had any performance
penalty for having the thing in place - after this forced chroot we never
touch it in lookups. BTW, pivot_root() is simpler that way.

BTW, we probably want to add mount --move <old> <new> - atomically moving
a subtree from one place to another. Code is there, we just need to
decide on API. Andries?

> So with some luck, distributors will switch to pivot_root sometime soon,
> when deploying 2.4. So if we drop all the old junk in 2.5, the amount of
> letter bombs should be small ;-)

Tomorrow I'll try to catch Erik and talk with him about that. I'm not sure
that I know anyone in Debian Install System Team (oh, boy... somebody sure
loved capital letters). And I've absolutely no idea who is doing that stuff
in other distributions...
Cheers,
Al

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/