On Jan 16, 2017, at 1:21 PM, James Bottomley wrote: > On Mon, 2017-01-16 at 13:02 -0500, Oleg Drokin wrote: >> On Jan 16, 2017, at 12:32 PM, James Bottomley wrote: >> >>> On Sun, 2017-01-15 at 18:38 -0500, Oleg Drokin wrote: >>>> A container support from filesystems is also very relevant to >>>> us >>>> since Lustre is used more and more in such settings. >>> >>> I've added the containers ML to the cc just in case. Can you add >>> more >>> colour to this, please? What container support for filesystems do >>> you >>> think we need beyond the user namespace in the superblock? >> >> Namespace access is necessary, we might need it before the superblock >> is there too (say during mount we might need kerberos credentials >> fetched to properly authenticate this mount instance to the server). > > The superblock namespace is mostly for uid/gid changes across the > kernel <-> filesystem boundary. That's on the kernel<->filesystem, but inside of the FS there might be other considerations that you might want to attach there. Say when you are encrypting the traffic to the server you want to use the right keys. It's all relatively easy when you have a separate mount there, so you can store the credentials in the superblock, but we lose on the cache sharing, for example (I don't know how important that is). > The actual container namespaces will already be set up by the time the > mount is done (assuming mount within a container), so you have them all > present. Usually you get the information for credentials from a > combination of the UTS namespace (host/domain name) and the mount > namespace (credentials provisioned to container filesystem). Yes, when mounting from a container it's possible to fetch this info and pass it around, is mounting from outside of the container important too? > Perhaps if you described the actual problem you're seeing rather than > try to relate it to what I said about superblock namespace (which is > probably irrelevant), we could figure out what the issue is. Right now the deployments are simple and we do not have any major issues (other than certain caching overzealousness that throws cgroup memory accounting off), but learning what other problems are there in this space and what we should be looking for. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
