Quoting Christian Seiler (christ...@iwakd.de):
> Hi Serge,
>
> >>+ /* Read-only bind-mounting... In older kernels, doing that
> >>required
> >>+ * to do one MS_BIND mount and then MS_REMOUNT|MS_RDONLY the
> >>same
> >>+ * one. According to mount(2) manpage, MS_BIND honors
> >>MS_RDONLY from
> >>+ * kernel 2.6.26 onwards. However, this apparently does not
> >>work on
> >>+ * kernel 3.8.
> >
> >I'm still not sure what is going on for you with this. Running
> >with the
> >latest 3.11 userns-enabled kernel (at ppa:ubuntu-lxc/kernel), I can
> >still do
> >
> > sudo mkdir /tmp/{a,b}
> > sudo mount -t tmpfs tmpfs /tmp/a
> > sudo mount --bind /tmp/a /tmp/b
> > sudo mount -o remount,bind,ro /tmp/b
> >
> >and end up with /tmp/b roand /tmp/a rw. This works for me in 3.2,
> >3.8,
> >and userns-enabled 3.11.
>
> I meant with that comment that mount --bind -o ro /tmp/a /tmp/b doesn't
> work directly, at least with 3.8, but you have to do two steps. This
> does not appear to be in accordance with the mount(2) manpage.
>
> >>Unfortunately, on that very same kernel, doing the
> >>+ * same trick as above doesn't seem to work either, there one
> >>needs
> >>+ * to ALSO specify MS_BIND for the remount, otherwise the entire
> >>+ * fs is remounted read-only or the mount fails because it's
> >>busy...
> >
> >That's actually understandable - there are two things which both have
> >a readonly.vs.readwrite state - the vfsmount, and the superblock. If
> >you don't add MS_BIND, then you are requesting remount of the
> >superblock.
>
> Yes, I see what you mean, but this is definitely a change in the
> behaviour of the kernel compared to previous versions. And that
> also means that (see other thread) bind-mounting a rootfs onto
> itself will not prevent a container from remounting the filesystem
> readonly on shutdown.
True, but (despite my having forgotten this in the earlier parts of
this thread) that *should* always have been the case. I distinctly
remember being disappointed a few years ago about it.
So yeah, we can't give up rootfs.hold :( Thanks for the reminder!
> Nevertheless, this should not be a problem for THIS patch, the
> current version should work with any reasonable kernel you may
> want to use LXC with.
Ok, thanks. I've looked over the patches and all look reasonable. I'm
going to set up two vms to really test these in (3.2 and 3.11 based) and
give them a going-over tonight or tomorrow, then intend to push them.
thanks,
-serge
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
