Re: reg: Stacked overlay support in Linux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jan 3, 2024 at 11:03 AM shanthosh krishna moorthy
<santy.accet@xxxxxxxxx> wrote:
>
> On Wed, Jan 3, 2024 at 1:57 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> >
> > On Tue, Jan 2, 2024 at 12:16 PM shanthosh krishna moorthy
> > <santy.accet@xxxxxxxxx> wrote:
> > >
> > > Hi,
> > >
> > > Is the Linux support for mounting overlay file system over another
> > > overlayfs lowerdir still supported?
> > > In kernel 4.1, this seems supported but not in 4.19 and above.
> > >
> > > //Create lower directoy on an overlayfs mount
> > > root@device2:/# mkdir /lower /upper /work /merged
> > >
> >
> > So /upper and /work are also on overlayfs?
> > Even if it did work, I think that some operations may have
> > unexpected results (creating opaque directory).
> >
> > > //User the 'lower' directory as lowerdir in overlayfs mount
> > > root@device2:/# mount -t overlay overlay -o
> > > lowerdir=/lower,upperdir=/upper,workdir=/work /merged
> > > mount: /merged: wrong fs type, bad option, bad superblock on overlay,
> > > missing codepage or helper program, or other error.
> > >
> > > root@device2:/# mount
> > > ...
> > > /dev/mmcblk0p9 on /overlay type ext4 (rw,noatime,nodelalloc,data=journal)
> > > overlayfs:/overlay on / type overlay
> > > (rw,noatime,lowerdir=/,upperdir=/overlay/bank_1,workdir=/overlay/work)
> > > ...
> > > root@device2:/#
> > >
> > > Could someone please shed some light on this error.
> >
> > The specific reason is to be found in the kernel log.
> > It may indicate that some configs or mount options could help.
> >
> > Please check the difference in CONFIG_OVERLAY_FS* values in
> > the two kernels you are comparing.
> >
> > Thanks,
> > Amir.
>
> Please find the dmesg log when the mount fails:
> overlayfs: filesystem on '/upper' not supported as upperdir
>
> //Linux 4.19 kernel config
> CONFIG_OVERLAY_FS=y
> # CONFIG_OVERLAY_FS_REDIRECT_DIR is not set
> CONFIG_OVERLAY_FS_REDIRECT_ALWAYS_FOLLOW=y
> # CONFIG_OVERLAY_FS_INDEX is not set
> # CONFIG_OVERLAY_FS_XINO_AUTO is not set
> # CONFIG_OVERLAY_FS_METACOPY is not set
>
> //Linux 4.1 kernel config
> CONFIG_OVERLAY_FS=y
>
> This seems related to the updates done as part of
> https://github.com/torvalds/linux/commit/7c03b5d45b8eebf0111125053d8fe887cc262ba6

Yes, you are right.

>
> So, overlay over overlay is not a valid usecase that could be supported anymore?

It is not a clear Yes or No question.
Note that the restriction regarding upperdir is that it is not "remote".
Not every overlayfs is "remote".
Overlayfs is "remote" if any of its lower layers are "remote".

OTOH, even an overlayfs that is not "remote" does not support
creating whiteouts and did not support storing overlayfs private xattrs
until very recently, so trying to use a non-"remote" overlayfs as upperdir
is a bad idea anyway - it will have some strange behavior and none
of the new features (e.g. metacopy) will be supported.

Could it be supported? I guess that now that we have
bc8df7a3dc03 ovl: Add an alternative type of whiteout
dad02fad84cb ovl: Support escaped overlay.* xattrs
we could support upperdir overlayfs,
but I really don't know if we should.

If you have an option to create upperdir/workdir not on overlayfs
that would be a much better option for you and the only option
on stable kernels.

Thanks,
Amir.





[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux