All of lore.kernel.org
 help / color / mirror / Atom feed
* UBIFS: ubifs_recover_leb() always execute fix_unclean_leb() even all the nodes are valid
@ 2021-12-24  7:58 韩仁杰
  2021-12-25  2:23 ` Zhihao Cheng
  0 siblings, 1 reply; 4+ messages in thread
From: 韩仁杰 @ 2021-12-24  7:58 UTC (permalink / raw)
  To: linux-mtd

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 ?



Thank you very much for any insight you can provide



-Han Renjie

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: UBIFS: ubifs_recover_leb() always execute fix_unclean_leb() even all the nodes are valid
  2021-12-24  7:58 UBIFS: ubifs_recover_leb() always execute fix_unclean_leb() even all the nodes are valid 韩仁杰
@ 2021-12-25  2:23 ` Zhihao Cheng
  2021-12-29 15:26   ` 韩仁杰
  0 siblings, 1 reply; 4+ messages in thread
From: Zhihao Cheng @ 2021-12-25  2:23 UTC (permalink / raw)
  To: 韩仁杰, linux-mtd

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: UBIFS: ubifs_recover_leb() always execute fix_unclean_leb() even all the nodes are valid
  2021-12-25  2:23 ` Zhihao Cheng
@ 2021-12-29 15:26   ` 韩仁杰
  2022-01-04  4:00     ` Zhihao Cheng
  0 siblings, 1 reply; 4+ messages in thread
From: 韩仁杰 @ 2021-12-29 15:26 UTC (permalink / raw)
  To: Zhihao Cheng; +Cc: linux-mtd

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: UBIFS: ubifs_recover_leb() always execute fix_unclean_leb() even all the nodes are valid
  2021-12-29 15:26   ` 韩仁杰
@ 2022-01-04  4:00     ` Zhihao Cheng
  0 siblings, 0 replies; 4+ messages in thread
From: Zhihao Cheng @ 2022-01-04  4:00 UTC (permalink / raw)
  To: 韩仁杰; +Cc: linux-mtd

Hi, 仁杰
> 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 meant unstable bits may look good in first recovery process, but they 
might be changed after running for a while.
> 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?
> 
Last written lebs are processed by ubifs_recover_leb(), some of them 
carry much usefull data, like GCHD and DATAHD(for creation nodes). In my 
opinion, fix_unclean_leb() is used to handle hardware error.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-01-04  4:01 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-24  7:58 UBIFS: ubifs_recover_leb() always execute fix_unclean_leb() even all the nodes are valid 韩仁杰
2021-12-25  2:23 ` Zhihao Cheng
2021-12-29 15:26   ` 韩仁杰
2022-01-04  4:00     ` Zhihao Cheng

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.