archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <>
To: www <>
Cc: Miklos Szeredi <>,
	Kevin Locke <>,
	overlayfs <>
Subject: Re: [PATCH] ovl: relax lookup error on mismatch origin ftype
Date: Fri, 30 Apr 2021 19:16:28 +0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Apr 30, 2021 at 12:59 PM www <> wrote:
> Hi Amir,
> Thank you very much for your help.  I have another question to clarify.
> >> 3. If we upgrade overlayfs separately, we are not very good at verifying that we have solved this problem, because the recurrence probability of this problem is very low. So I want to ask, how can we quickly reproduce this problem?
> >Re-creating a lower squashfs after files have been copied to upper should
> >reproduce the problem quite often.
> Does the re-creating lower squashfs here mean that remount squashfs?
> I've tested dozens of times in the remount way, but I haven't found this problem again?
> My test steps are:
> 1). umount lower squashfs;
> 2). modify the file in upper dir;
> 3). mount lower squanshfs;
> 4). restart service(it will re-parse the modified file)  or reboot the system and the problem didn't happen.

No. That's not what I mean by re-creating lower fs.
What I mean is that overlayfs is the file is question is in the squashfs
image and has been copied up.

I don't know where the squashfs image you are using comes from
but I am guessing you have replaced it with a new squashfs image.
In the new squashfs image, files have different inode numbers.

I reckon this behavior is common for OpenWRT where the system
image is being upgraded.

> At 2021-04-27 18:28:26, "Amir Goldstein" <> wrote:
> >We get occasional reports of lookup errors due to mismatched
> >origin ftype from users that re-format a lower squashfs image.
> >
> >Commit 13c6ad0f45fd ("ovl: document lower modification caveats")
> >tries to discourage the practice of re-formating lower layers and
> >describes the expected behavior as undefined.
> >
> >Commit b0e0f69731cd ("ovl: restrict lower null uuid for "xino=auto"")
> >limits the configurations in which origin file handles are followed.
> >
> >In addition to these measures, change the behavior in case of detecting
> >a mismatch origin ftype in lookup to issue a warning, not follow origin,
> >but not fail the lookup operation either.
> >
> >That should make overall more users happy without any big consequences.
> >
> We can't do that. When overlayfs reports an error, there may be some very important files that cannot be correctly parsed, resulting in some important services can not be started smoothly, which directly affects the use of the whole system.

Well, that is the purpose of my patch -
When overlayfs reports the warning it will NOT prevent reading the
file, so it should NOT make the whole system unusable.


  parent reply	other threads:[~2021-04-30 16:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27 10:28 Amir Goldstein
     [not found] ` <>
2021-04-30 16:16   ` Amir Goldstein [this message]
     [not found]     ` <>
2021-05-06 10:25       ` Amir Goldstein
     [not found]         ` <>
2021-05-07  6:09           ` Amir Goldstein
2021-07-21 13:10 ` Miklos Szeredi
2021-07-21 14:16   ` Amir Goldstein
2021-07-21 14:33     ` Miklos Szeredi
2021-07-21 14:46       ` 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:

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

  git send-email \ \ \ \ \ \ \
    --subject='Re: [PATCH] ovl: relax lookup error on mismatch origin ftype' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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 NNTP newsgroup(s).