[lxc-devel] [RFC] yet another rootfs pinning change

Serge Hallyn serge.hallyn at ubuntu.com
Tue Oct 1 03:36:51 UTC 2013


Quoting Christian Seiler (christian at iwakd.de):
> Hi,
> 
> I'm attaching a patch that makes additional chanes to the rootfs
> pinning mechanism. It can also be found under:
> <https://github.com/chris-se/lxc/tree/rootfs-pinning>
> 
> This patch implements things that were floating around in discussions
> earlier. I know it is still in flux of how to best handle ro-remounts
> at shutdown, so the idea is that this patch would be applied if lxc
> will stick with the pinning mechanism. (Which seems likely to me at
> this point because of the kernel change that remount without bind will
> still remount the whole filesystem, see automounting improvements.)
> 
> A bit of rationale for the choices:
> 
>  - Don't auto-delete the file after creation because of NFS problems.

Barring misunderstanding on my part, I disagree with this.
The  deleted filename just gets renamed to another hidden
file, which is deleted on file close.  If two files named 'b'
are both held open and deleted by two different tasks (even
on the same host) they are given different (sequential) names.

So I think it's better to continue to delete them as we were.

Is there another side effect I'm not considering?

>  - But then the file will lurk around the system for the whole time, so
>    make it hidden, i.e. make the filename start with a dot.
>  - Cleanup after ourselves at shutdown. This will still leave files
>    in case of a power failure.
>  - Because we now cleanup after ourselves at shutdow, and a rootfs
>    could be used by potentially multiple containers, encode the pid of
>    lxc-start in the filename. That way, even with cleanup, only after
>    the last container using that rootfs ends the last hold file will be
>    released.
>  - Continue to NOT use O_EXCL, see previous discussions, since we don't
>    want container startup to fail after reboot with power failure.
> 
> Note that the hold file is inside the rootfs now (previously it was
> in a directory one level higher), but that was already the case with my
> previous rootfs pinning commit that's already applied to master. The
> rationale behind this is that I've run into the situation where I have
> rootfs on a separate filesystem, but that this filesystem is already
> mounted on the host (for various reasons), such that a hold file in the
> parent directory will be of no use. But the current change means that
> the hold file will leak into the container. I do not think this is
> problematic, since the worst thing someone inside the container could
> do is unlink it, and that does not affect the basic functionality.
> 
> -- Christian
> 
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________
> Lxc-devel mailing list
> Lxc-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lxc-devel




More information about the lxc-devel mailing list