linux-unionfs mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: shanthosh krishna moorthy <santy.accet@gmail.com>
Cc: linux-unionfs@vger.kernel.org
Subject: Re: reg: Stacked overlay support in Linux
Date: Wed, 3 Jan 2024 12:17:02 +0200	[thread overview]
Message-ID: <CAOQ4uxg__KvqL6==OoaP8oVqG=M+xi-8gLQq_WY2N+qK5xvJ4g@mail.gmail.com> (raw)
In-Reply-To: <CAPPzL71Y_g2M7Nuxgei1sx8NkmYPvsDDK-S=f4v4QyjnsVki2A@mail.gmail.com>

On Wed, Jan 3, 2024 at 11:03 AM shanthosh krishna moorthy
<santy.accet@gmail.com> wrote:
>
> On Wed, Jan 3, 2024 at 1:57 AM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Tue, Jan 2, 2024 at 12:16 PM shanthosh krishna moorthy
> > <santy.accet@gmail.com> 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.

      reply	other threads:[~2024-01-03 10:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-02 10:16 reg: Stacked overlay support in Linux shanthosh krishna moorthy
2024-01-02 20:27 ` Amir Goldstein
2024-01-03  9:03   ` shanthosh krishna moorthy
2024-01-03 10:17     ` Amir Goldstein [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOQ4uxg__KvqL6==OoaP8oVqG=M+xi-8gLQq_WY2N+qK5xvJ4g@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=santy.accet@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).