From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Alexander Larsson <alexl@redhat.com>
Cc: Amir Goldstein <amir73il@gmail.com>,
Miklos Szeredi <miklos@szeredi.hu>,
linux-unionfs@vger.kernel.org
Subject: Re: [PATCH v2 4/5] ovl: Support creation of whiteout files on overlayfs
Date: Fri, 8 Sep 2023 16:44:34 +0800 [thread overview]
Message-ID: <dd432c83-3731-ce3a-a8f5-6175b3643fd7@linux.alibaba.com> (raw)
In-Reply-To: <CAL7ro1EsjzNeYAbjPN3HnB7Sq4D48my3PGhPG5L+4DTXzA9xFw@mail.gmail.com>
Hi Alexander,
On 2023/9/8 16:30, Alexander Larsson wrote:
>
>
> On Fri, Sep 8, 2023 at 4:21 AM Gao Xiang <hsiangkao@linux.alibaba.com <mailto:hsiangkao@linux.alibaba.com>> wrote:
>
..
> > I hope I got the use case correctly?
> Sorry for the dumb questions below. I'm interested in the use cases:
> after checking the previous github issue and emails (sorry if I'm
> still missing something), I'm curious about this too.
>
> I totally understand how it plans to work and how it works (by using
> escape xattr prefixes) but I'm not sure if I'm quite understand the
> original issue:
>
> Do composefs use cases store overlayfs xattrs in the meta-only layer?
> if so, such layer is actually hand-crafted by mkfs. Why do we need
> a way to keep escape xattrs on the underlay overlayfs? Does the
> other layer are data-only layers (do we keep some overlay xattrs in
> these data-only layers)?
>
>
> Here is the problem statement:
>
> I use composefs for my rootfs. I want to be able to store any kind of files in it and have them be visible in the final rootfs. In particular I want it to contain a whiteout file, because I want to mount an additional overlayfs where the lowerdir is stored on the rootfs (i.e. in the composefs mount).
>
> The naive way to accomplish this is to just put a chardev(0,0) file in the erofs image that is the metadata layer in the rootfs overlayfs. I mean, that is what we do with all other file types.
>
> However, if you were to do this, then the overlayfs that composefs uses will interpret the whiteout as masking out a file from the data-only layer in the composefs mount. This means the whiteout file we wanted is not visible in the final rootfs.
Thanks for your explanation. That is helpful for me to
know what was happening here.
Okay, I got the point, so basically I think the original
use case is to have a way to "make such whiteouts in the
meta-only layer that overlayfs doesn't interpret/drop in
the composefs mount" (yes, a special whiteout is a
workable solution. )
Personally, there could be several ways to resolve this.
I have no more questions, thanks for the reply :)
Thanks,
Gao Xiang
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Alexander Larsson Red Hat, Inc
> alexl@redhat.com <mailto:alexl@redhat.com>alexander.larsson@gmail.com <mailto:alexander.larsson@gmail.com>
next prev parent reply other threads:[~2023-09-08 8:44 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 11:05 [PATCH v2 0/5] Support nested overlayfs mounts Alexander Larsson
2023-08-17 11:05 ` [PATCH v2 1/5] ovl: Move xattr support to new xattrs.c file Alexander Larsson
2023-08-17 12:48 ` Amir Goldstein
2023-08-17 11:05 ` [PATCH v2 2/5] ovl: Add OVL_XATTR_TRUSTED/USER_PREFIX_LEN macros Alexander Larsson
2023-08-17 12:48 ` Amir Goldstein
2023-08-17 11:05 ` [PATCH v2 3/5] ovl: Support escaped overlay.* xattrs Alexander Larsson
2023-08-17 14:31 ` Amir Goldstein
2023-08-17 15:00 ` Alexander Larsson
2023-08-17 11:05 ` [PATCH v2 4/5] ovl: Support creation of whiteout files on overlayfs Alexander Larsson
2023-08-17 13:40 ` Amir Goldstein
2023-08-21 10:59 ` Miklos Szeredi
2023-08-21 12:55 ` Alexander Larsson
2023-08-21 13:25 ` Amir Goldstein
2023-08-21 15:31 ` Alexander Larsson
2023-08-21 15:40 ` Miklos Szeredi
2023-08-21 20:07 ` Alexander Larsson
2023-08-22 13:22 ` Alexander Larsson
2023-08-22 13:56 ` Miklos Szeredi
2023-08-22 14:25 ` Alexander Larsson
2023-08-22 14:36 ` Alexander Larsson
2023-08-22 15:02 ` Miklos Szeredi
2023-08-22 15:31 ` Alexander Larsson
2023-08-22 15:30 ` Amir Goldstein
2023-08-22 15:43 ` Alexander Larsson
2023-08-22 15:57 ` Amir Goldstein
2023-08-22 16:18 ` Miklos Szeredi
2023-08-22 17:29 ` Amir Goldstein
2023-09-08 2:21 ` Gao Xiang
[not found] ` <CAL7ro1EsjzNeYAbjPN3HnB7Sq4D48my3PGhPG5L+4DTXzA9xFw@mail.gmail.com>
2023-09-08 8:44 ` Gao Xiang [this message]
2023-08-23 8:51 ` Alexander Larsson
2023-08-23 13:13 ` Alexander Larsson
2023-08-23 13:21 ` Alexander Larsson
2023-08-23 14:42 ` Amir Goldstein
2023-08-23 14:52 ` Miklos Szeredi
2023-08-23 15:02 ` Alexander Larsson
2023-08-23 15:50 ` Amir Goldstein
2023-08-24 9:56 ` Alexander Larsson
2023-08-24 11:43 ` Amir Goldstein
2023-08-24 14:22 ` Alexander Larsson
2023-08-25 8:40 ` Amir Goldstein
2023-08-25 11:29 ` Alexander Larsson
2023-08-25 14:39 ` Amir Goldstein
2023-08-23 14:50 ` Alexander Larsson
2023-08-17 11:05 ` [PATCH v2 5/5] ovl: Add documentation on nesting of overlayfs mounts Alexander Larsson
2023-08-17 13:31 ` Amir Goldstein
2023-08-17 13:59 ` Alexander Larsson
2023-08-17 14:45 ` [PATCH v2 0/5] Support nested " Amir Goldstein
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=dd432c83-3731-ce3a-a8f5-6175b3643fd7@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=alexl@redhat.com \
--cc=amir73il@gmail.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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).