All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhihao Cheng <chengzhihao1@huawei.com>
To: 韩仁杰 <hanrenjie123@gmail.com>
Cc: <linux-mtd@lists.infradead.org>
Subject: Re: UBIFS: ubifs_recover_leb() always execute fix_unclean_leb() even all the nodes are valid
Date: Tue, 4 Jan 2022 12:00:04 +0800	[thread overview]
Message-ID: <0b3bb085-2313-e965-9402-1e100def5425@huawei.com> (raw)
In-Reply-To: <CADPmmj6kcEYYHE4w-BKQ2y4ceATTU7N=h-M821ksrt1eTLpiOg@mail.gmail.com>

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/

      reply	other threads:[~2022-01-04  4:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

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=0b3bb085-2313-e965-9402-1e100def5425@huawei.com \
    --to=chengzhihao1@huawei.com \
    --cc=hanrenjie123@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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.