UBIFS: ubifs_recover_leb() always execute fix_unclean_leb() even all the nodes are valid

[韩仁杰]

Hi Zhihao

>I guess imporved ubifs_recover_leb() can handle unstable writing on nand
>flash by calling fix_unclean_leb() after a power-cut. Last programming
>before power-cut on PEB is untrustable, even though the PEB is
>recognized as valid for the moment, there maybe another data content
>read from the same PEB after a while. Just like commit said, unstable
>bits, which may fail ubifs_scan().

Sorry for the late reply. I saw the comment in the commit, but I don’t
understand the meaning of unstable bits very well. Does it mean that
unstable bits may appear in the area after the current offset and cause
subsequent write operations to fail? But when I copy the original data
to another PEB, there should be the same probability that unstable bits
will appear?
I have a guess. Is it possible that the data is copied to another PEB
because there may be more useless data in the current PEB in order
to recover the entire PEB?

Zhihao Cheng <chengzhihao1 at huawei.com> 于2021年12月25日周六 10:23写道：
>
> 在 2021/12/24 15:58, 韩仁杰 写道:
> Hi, 仁杰
> > I've been working on Linux 4.4.60 recently When using UBIFS file system,
> >
> > I recently encountered a problem that every time I power off and restart,
> >
> > I will enter the recovery process of UBIFS.
> >
> >
> >
> > I do understand the reason for entering recovery during startup, and the
> >
> > main  purpose of ubifs_recover_leb() is to deal with an invalid node and
> >
> > make ubifs mount successfully. But even if there are no invalid nodes,
> >
> > ubifs_recover_leb() will call  fix_unclean_leb(), which results in flash’s erase
> >
> > and write operations during startup.
> >
> >
> >
> > I checked the modify history of kernel/fs/ubifs/recovery.c, and found a related
> >
> > commit:
> >
> >    http://git.infradead.org/linux.git/commitdiff/7c47bfd0dbb20e5d7fa4e37cfd76bb7
> >
> > 3d39b32b4?hp=617992069513c1e789c707c4d75ff03bf7dd0fb0.
> >
> >
> >
> > In the commit, variable "need_clean" was deleted. My question is that
> > whether it is
> >
> > necessary to execute fix_unclean_leb() if there are no invalid node ?
> > I am not sure if
> >
> > there are some additional considerations I didn't think of ?
>
> According to the description in commit
> 7c47bfd0dbb20e5d7fa4e37cfd76bb73d39b32b4("UBIFS: always cleanup the
> recovered LEB"):
> "Now when we call 'ubifs_recover_leb()' only for LEBs which are
> potentially corrupted (i.e., only for last buds, not for all of them),
> we can cleanup every LEB, not only those where we find corruption. The
> reason - unstable bits. Even though the LEB may look good now, it might
> contain unstable bits which may hit us a bit later."
>
> I guess imporved ubifs_recover_leb() can handle unstable writing on nand
> flash by calling fix_unclean_leb() after a power-cut. Last programming
> before power-cut on PEB is untrustable, even though the PEB is
> recognized as valid for the moment, there maybe another data content
> read from the same PEB after a while. Just like commit said, unstable
> bits, which may fail ubifs_scan().