On Wed, Feb 15, 2017 at 10:37 AM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > Djalal Harouni <tixxdz@xxxxxxxxx> writes: > >> On Mon, Feb 13, 2017 at 11:15 AM, Eric W. Biederman >> <ebiederm@xxxxxxxxxxxx> wrote: >>> James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> writes: > >>>> So is this. Basically anything that begins by mounting gets a super >>>> block and can use the s_user_ns to map from the filesystem view to the >>>> kernel view of ids. Apart from greater sophistication in the >>>> parametrisation, it sounds like we have all the machinery you need. >>>> I'm sure the containers people will consider reasonable patches to >>>> change this. >>> >>> Yes. >>> >>> And to be clear we have all of that merged now and mostly present and >>> hooked up in all filesystems without any shiftfs like changes needed. >>> >>> To use this with a filesystem a last pass needs to be had to verify that >>> the cases where something does not map are handled cleanly. >> >> Still this does not answer the question how to dynamically >> *attach/share* data or read-only volumes as defined by >> orchestration/container tools into several containers. Am I missing >> something or is the plan to have per superblock mount for each one ? > > Agreed. That is a related problem and the problem that shiftfs > is working to solve. > > If you only need a single mapping the infrastructure is basically done > in the kernel today. If you need multiple mappings we need something > more. Yes, I'm asking since there is that vfs+userns proposed approach that I linked in this thread, that deals with this particular problem: in which mount namespace<->container the volume appears, maybe that can be used on top of the s_user_ns ... Thanks! -- tixxdz
