[lkml]   [2017]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectUsing overlay on top of overlay

For few kernel releases overlay supported using it on top of another

FWIW there was a regression related to this "feature" in 4.2:
but it was fixed:

Starting with kernel 4.4 this "feature" seems to be disabled explicitly:

Disabling commit says that it "does not make sense" but actually there
seem to be few projects that are looking for such a solution, see:

I can't really elaborate on above cases but I have a similar need for
my OpenWrt system running LXC (Linux Containers).

First of all OpenWrt uses overlay to "merge" squashfs and some writable
filesystem partition. It needs squashfs due to dealing with devices with
really small flashes (down to 4 - 8 MiB). Then it stores all its LXC
containers in the /srv/lxc/.

Secondly LXC itself uses overlay feature in few places, e.g.
1) lxc.rootfs with the overlayfs:lower:upper syntax
2) lxc.mount.entry with the fstab syntax

As you can guess LXC simply assumes overlay can be used and doesn't
check if the host system uses it for directory holding container data.
This breaks LXC because kernel refuses mounting dir with some message
overlayfs: filesystem on '/foo' not supported as upperdir

I managed to find a workaround for this. As OpenWrt uses:
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
I can simply replace
(same for workdir) but this isn't really a user friendly solution.

I would like to ask if use cases I described above make any sense to
Is there any chance someone could work on a proper support for overlay
on top of overlay and enabling it again?

 \ /
  Last update: 2017-12-13 11:11    [W:0.048 / U:1.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site