From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Jingbo Xu <jefflexu@linux.alibaba.com>,
Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
overlayfs <linux-unionfs@vger.kernel.org>,
Xiang Gao <xiang@kernel.org>, "zhangyi (F)" <yi.zhang@huawei.com>
Subject: Re: [potential issue, question] whiteout shows up in merged directory
Date: Mon, 4 Sep 2023 21:27:18 +0800 [thread overview]
Message-ID: <fe799167-249b-8fe2-a6c8-b222ac9acaf0@linux.alibaba.com> (raw)
In-Reply-To: <9a89150e-cd84-c541-8088-41c2dfe863ac@linux.alibaba.com>
On 2023/9/4 20:49, Jingbo Xu wrote:
...
>
> Thanks for the reply and it's really helpful to me.
>
> I can understand in the normal use case, whiteout can not appear in
> non-merged directory without origin xattr, except it's hand crafted.
>
> But indeed we suffer from this issue in the tarfs for erofs-utils we are
> developing. As described previously, in tarfs mode erofs-utils can
> convert each tar layer into one separate erofs image, and then merge
> these erofs images into one merged erofs image in a overlayfs-like model.
>
> Suppose:
>
> layer 0 + layer 1 + layer 2 --> merged
> /foo/bar /foo/bar (whiteout)
>
>
> To speed the merging process, we may merge the two top-most layers
> (layer 1 and layer 2) first, and then make layer0 merged into the final
> merged image as:
>
>
>
> layer 1 + layer 2 --> merged-intermediate
> /foo/bar /foo/bar (whiteout)
>
> layer0 + merged-intermediate --> merged
I could add some more background to this, assuming layer 0 is a
baseos layer (e.g. almost all images use this layer); and layer 1 +
layer 2 belongs to some specific workload images;
since layer 1 + layer 2 are always used together, so we could merge
layer 1 + layer 2 as a new merged layer to avoid extra overhead of
too many overlay layer dirs (but to simplify, here we just illustrate
layer 1 and layer 2, there could be layer 3, 4, ...), but layer 1 +
layer 2 has no relationship with layer 0 in principle (in principle,
merge tool doesn't need to know if layer 0 or any underlay layer
exists).
So if we merge layer 1 + layer 2 here first, and use layer0 together
with the merged layer, it could generate such whiteout cases
described before.
Anyway, we could work around this in the merge tool, but I'm not
sure if it's a design constaint of overlayfs.
Thanks,
Gao Xiang
>
> Then there comes the problem: when merging layer1 and layer2, I need to
> keep the whiteout in the intermediate merged image though the target of
> the whiteout has showed up in underlying layer (/foo/bar in layer 1),
> because I have no idea if "/foo/bar" exits in the following further
> underlying layer (layer 0). Reusing this logic, the whiteout is kept
> there in the final merged image after merging layer0 and
> merged-intermediate.
>
> Then if "/foo" is not a merged directory, the "/foo/bar" whiteout will
> be exposed in the overlayfs unexpectedly.
>
> Currently we work around this in erofs-utils side. Apart from setting
> origin xattr on the parent directory of the whiteout, I'm not sure if
> the above use case is reasonable enough to fix this in the kernel side.
>
next prev parent reply other threads:[~2023-09-04 13:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-04 7:47 [potential issue, question] whiteout shows up in merged directory Jingbo Xu
2023-09-04 8:57 ` Amir Goldstein
2023-09-04 12:49 ` Jingbo Xu
2023-09-04 13:27 ` Gao Xiang [this message]
2023-09-04 14:07 ` Amir Goldstein
2023-09-04 14:38 ` Gao Xiang
2023-09-04 15:03 ` Amir Goldstein
2023-09-04 15:12 ` Gao Xiang
2023-09-04 15:01 ` Jingbo Xu
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=fe799167-249b-8fe2-a6c8-b222ac9acaf0@linux.alibaba.com \
--to=hsiangkao@linux.alibaba.com \
--cc=amir73il@gmail.com \
--cc=jefflexu@linux.alibaba.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=xiang@kernel.org \
--cc=yi.zhang@huawei.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