Tejun Heo <teheo@xxxxxxx> writes: > Kirill Korotaev wrote: >> Tejun Heo wrote: >>> I thought something like supermount plus some twists or fuse based sysfs >>> proxy would fit better. Dunno whether or how uevent and polling stuff >>> can work that way tho. Note that sysfs no longer keeps dentries and >>> inodes pinned. It might make the shared dentry stuff harder. >> >> We simply don't share sysfs dentries/inodes between containers. >> It's not that frequently used time critical fs to be super-optimized... :) > > OIC, dentries and inodes are not shared. Good then. Agreed that sysfs > doesn't need to be super-optimized as long as big machines aren't > penalized too much (both memory and cpu cycle wise). > >> I don't like the idea with fuse, since sysfs exports kernel-related stuff, >> so doing it via user-space would be pain. > > Yeah, it would be cumbersome to setup but it's also fast and easy to toy > with for prototypes at least. How close are we to the point where we can get mount sysfs multiple times and get multiple dentry trees with different super blocks? That really does sound like the right way to go. Especially as it simplifies the monitoring of containers. If you want to watch what the view looks like in some container your bind mount his sysfs and look at that. If we can do that the dcache side at least will be beautiful. And with a little care we may be able to reduce the work to a special case in lookup, some extra handling to mark directories as belonging only to a certain mount of sysfs. If we can find something that is stupid and simple I'm all for that. To reach the no-kobj utopia we may also need a special device_migrate that is a super set of device_rename (because sometimes we need to rename devices when we move them between namespaces). So are we close to having a sysfs that we can have multiple super blocks for? I'm on a sysctl tangent, but I should be able to look at that in just a little bit. Eric _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers