[lxc-devel] relative paths in mounts?

[Michael Tokarev]

25.11.2010 15:53, Daniel Lezcano wrote:
> On 11/23/2010 07:50 PM, Michael Tokarev wrote:
>> 23.11.2010 13:25, Michael Tokarev wrote:
>>   
>>> Hello again.
>>>
>>> I asked this question before, but got no (satisfactory)
>>> answer. So here it goes again.
>>>
>>> Why not chdir into the root of container right when
>>> the root filesystem is (bind-)mounted, and let all
>>> mount entries to be relative to the container root?
>>>
>>> Even more, to warn if lxc.mount[.entry] contains
>>> absolute path for the destination directory (or a
>>> variation of this, absolute and does not start with
>>> container root mount point)?
>>>
>>> This way, all mounts will look much more sane, and
>>> it will be much easier to move/clone containers -
>>> by changing only lxc.rootfs.
>>>
>>> I can easily cook a patch for that (it's trivial),
>>> but I want to hear any disagreements before ;)
>>>
>>> I do it this way locally since the beginning, by
>>> chdir'ing to the proper directory (rootfs) before
>>> running lxc-start (in a startup script), but this
>>> is now broken in 0.7.3 which bind-mounts rootfs
>>> somewhere in /usr/lib/lxc.
>>>      
>> I looked into the code and it turned out to be easier
>> than I thought.  Something like the attached.  It
>> just qualifies the relative paths found in mount
>> entries with rootfs->mount, as all other places
>> (/dev processing etc) does.
>>
>> Just in case,
>>
>> Signed-Off-By: Michael Tokarev<mjt at tls.msk.ru>
> 
> What happens if there is no rootfs specified in the configuration file ?

Yes good question.  Attached is the updated patch that
has 2 codepaths - when root is separate or system.

Compile-tested only for now, I'll do some testing tomorrow.

Signed-Off-By: Michael Tokarev<mjt at tls.msk.ru>

/mjt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resolve-relative-mounts.diff
Type: text/x-patch
Size: 3005 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20101201/ac90784d/attachment.bin>