Re: Maximum mountpoints + chrooted login
On Wed, 27 Jun 2001, Magnus Naeslund(f) wrote: > I'll wait for 2.5 then... > Where's that namespace patch located? The last one I've put on anonftp was against 2.4.6-pre2 (namespaces-a-S6-pre2, on ftp.math.psu.edu/pub/viro). It still includes tons of fs/super.c cleanups and fixes - they still need to be merged into the tree. > Now in 2.4.5 it's darn slow to _unmount_, it's like 100 times faster to > mount than unmount :) Erm... The last umount should sync everything on given fs. You don't read a hundred megabytes upon mount but you can easily get such amount of dirty data after working for a while ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Maximum mountpoints + chrooted login
From: "Alexander Viro" <[EMAIL PROTECTED]> > [snip] > > I didn't go for proper solution in 2.4.0-test*). However, instead of > crufting up kinda-sorta namespaces one could use the real thing. Relevant > cleanups of superblock handling will go in in 2.5.very_early and the > rest of patch (namespace proper) takes about 10Kb. > I'll wait for 2.5 then... Where's that namespace patch located? > You can simply say clone(CLONE_NAMESPACE,NULL) and you get an independent > set of mounts to play with. mount/umount whatever you want before dropping > the root priveleges. All children of that process will share its namespace. > When the last one goes away everything will be garbage-collected - no > need to umount anything on logout. > Lovely! > > With the mntcache in - not really. It fixes the main performance problem. Now in 2.4.5 it's darn slow to _unmount_, it's like 100 times faster to mount than unmount :) Cheers Magnus Naeslund -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Programmer/Networker [|] Magnus Naeslund PGP Key: http://www.genline.nu/mag_pgp.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Maximum mountpoints + chrooted login
On Wed, 27 Jun 2001, Magnus Naeslund(f) wrote: > I was thinking of doing a chrooted login for some ssh accounts. > The plan is this: [snip CLONE_NAMESPACE-by-hands] > Does this seem like a bad idea? > (then please tell me why :)) Mostly because there's a better way to do that. Yes, such scheme would work (that + massive pending fs/super.c cleanups was the main reason why I didn't go for proper solution in 2.4.0-test*). However, instead of crufting up kinda-sorta namespaces one could use the real thing. Relevant cleanups of superblock handling will go in in 2.5.very_early and the rest of patch (namespace proper) takes about 10Kb. You can simply say clone(CLONE_NAMESPACE,NULL) and you get an independent set of mounts to play with. mount/umount whatever you want before dropping the root priveleges. All children of that process will share its namespace. When the last one goes away everything will be garbage-collected - no need to umount anything on logout. > One problem could be the _massive_ mounts, 3*online_users. > Are there any limits/drawbacks doing it like this? With the mntcache in - not really. It fixes the main performance problem. Memory cost is sizeof(struct vfsmount)*total amount of mountpoints. I.e. about 100 bytes per mountpoint. That's it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
