linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: www <ouyangxuan10@163.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Kevin Locke <kevin@kevinlocke.name>,
	overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: Re: Re: [PATCH] ovl: relax lookup error on mismatch origin ftype
Date: Fri, 7 May 2021 09:09:54 +0300	[thread overview]
Message-ID: <CAOQ4uxj2GcLds=4cj4RLb9Eqh3oA=wAnL0B5rYOp2DGDJ+wh=A@mail.gmail.com> (raw)
In-Reply-To: <39ca38d.1ec8.17944f144b3.Coremail.ouyangxuan10@163.com>

On Fri, May 7, 2021 at 6:51 AM www <ouyangxuan10@163.com> wrote:
>
> Hi Amir,
>
>
>
>
> At 2021-05-06 18:25:51, "Amir Goldstein" <amir73il@gmail.com> wrote:
> >On Thu, May 6, 2021 at 12:49 PM www <ouyangxuan10@163.com> wrote:
> >>
> >> Hi Amir,
> >>
> >>
> >>
> >> At 2021-05-01 00:16:28, "Amir Goldstein" <amir73il@gmail.com> wrote:
> >> >On Fri, Apr 30, 2021 at 12:59 PM www <ouyangxuan10@163.com> 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.
> >> >
> >> https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/initrdscripts/files/obmc-init.sh   (init file)
> >> ...
> >> line 376: mount  /run/image-rofs /run/initramfs/ro -t  squanshfs -o ro,loop          (line 358, set copy-base-filesystem-to-ram=y)
> >> ...
> >> line 416: mkdir -p $upper/var/log      --- new add line, not in the file
> >> line 417: mount -t overlayfs -o lowerdir=run/initramfs/ro,upperdir=run/initramfs/rw/cow,workdir=run/initramfs/rw/work  cow  /root
> >>  ...
> >> I would like to ask if the newly added line(line 416)  or "set set copy-base-filesystem-to-ram=y" causes this problem?(This folder is created and the value is set every time the system starts, but the probability of problems is not high)
> >> There are no other changes.
> >>
> >>
> >
> >I don't know.
> >
> >I am not sure what wasn't clear in my answer.
> >
> >The lowerfs image, namely /run/image-rofs in your script can be downloaded
> >from tftp or from the web. I have no idea what actually happens in your setup.
> >
> the /run/image-rofs image is copied form flash.
> line 359:  test ! -e /run/image-rofs && ! cp $rodev /run/image-rofs        -- the $rodev is mtd4
>
>
> >Every time you run this init script this lower fs image may change, while the
> >upper f2fs rwfs does not change.
> >When that happens, it MAY cause the reported issue.
> >
> the /run/image-rofs is squashfs, readonly, cannot be modified.
> Do you mean that when I upgrade the new firmware, rofs (squashfs) has been updated (rofs has been modified), is it easy to have this problem?
>

YES!

Thanks,
Amir.

  parent reply	other threads:[~2021-05-07  6:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27 10:28 Amir Goldstein
     [not found] ` <123ca2cd.45f7.1792236c0e9.Coremail.ouyangxuan10@163.com>
2021-04-30 16:16   ` Amir Goldstein
     [not found]     ` <74a06ca.4928.17941146e4b.Coremail.ouyangxuan10@163.com>
2021-05-06 10:25       ` Amir Goldstein
     [not found]         ` <39ca38d.1ec8.17944f144b3.Coremail.ouyangxuan10@163.com>
2021-05-07  6:09           ` Amir Goldstein [this message]
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:
  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='CAOQ4uxj2GcLds=4cj4RLb9Eqh3oA=wAnL0B5rYOp2DGDJ+wh=A@mail.gmail.com' \
    --to=amir73il@gmail.com \
    --cc=kevin@kevinlocke.name \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=ouyangxuan10@163.com \
    --subject='Re: Re: Re: [PATCH] ovl: relax lookup error on mismatch origin ftype' \
    /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

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).