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