Re: Re: Re: [PATCH] ovl: relax lookup error on mismatch origin ftype

[Amir Goldstein <amir73il@gmail.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.