From: Richard Weinberger <richard@nod.at>
To: "Bean Huo 霍斌斌 (beanhuo)" <beanhuo@micron.com>,
"Artem Bityutskiy" <dedekind1@gmail.com>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Brian Norris" <computersforpeace@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Boris Brezillon" <boris.brezillon@free-electrons.com>,
"Peter Pan 潘栋 (peterpandong)" <peterpandong@micron.com>,
"Karl Zhang 张双锣 (karlzhang)" <karlzhang@micron.com>,
"Jason Tian 田晓强 (jasontian)" <jasontian@micron.com>
Subject: Re: [PATCH 1/1] fs:ubifs:recovery:fixup UBIFS cannot recover master node issue
Date: Thu, 28 Jan 2016 10:31:58 +0100 [thread overview]
Message-ID: <56A9E00E.1070706@nod.at> (raw)
In-Reply-To: <A765B125120D1346A63912DDE6D8B6310BF65A47@NTXXIAMBX02.xacn.micron.com>
Bean,
Am 28.01.2016 um 03:42 schrieb Bean Huo 霍斌斌 (beanhuo):
>> This needs a much more detailed explanation.
>> In which scenarios on SLC NAND can you get such an unmountable UBIFS?
>
>
> It is my mistake involved SLC NAND.
> Definitely, SLC NAND does not exist two pages being damaged within one block.
> I mean that master should be recovered as long as one good master block exists.
> I think, at least this method is more reasonable.
> My question is that why UBI doesn't recover master node for this scenario?
UBIFS assumes that on SLC NAND already written pages must not
corrupt. It can deal with the fact that pages can get damaged while writing them (think of a power cut).
But if page X is written and UBIFS moves over to X + 1, X must never corrupt.
If this happens, something very nasty happened and UBIFS cannot operate correctly.
With your patch it may mount somehow but *will* die or lose data soon or later as the same assumptions
apply to all other UBIFS operations. It is not just about master nodes.
Master nodes are the messenger.
UBIFS' strict checks turned out to be very valuable in the past to identify driver/MTD issues.
This is why I like them so much.
>> Maybe UBIFS is too strict and NAND behaves differently than UBIFS expects
>> but we need to understand it in depth.
> For this, I think, maybe MLC NAND had not been released yet when UBI initial design.
> I would like to send my version 2 patch based on your suggestion.
If you can explain in detail why UBIFS' assumptions are wrong and how such corruptions can happen
on SLC we can talk.
But I think then we'd have to redo a lot of UBI and UBIFS code.
Thanks,
//richard
next prev parent reply other threads:[~2016-01-28 9:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-11 8:26 [PATCH 1/1] fs:ubifs:recovery:fixup UBIFS cannot recover master node issue Bean Huo 霍斌斌 (beanhuo)
2015-12-11 9:12 ` Richard Weinberger
2015-12-14 3:55 ` Bean Huo 霍斌斌 (beanhuo)
2015-12-14 18:00 ` Richard Weinberger
2016-01-28 2:42 ` Bean Huo 霍斌斌 (beanhuo)
2016-01-28 9:31 ` Richard Weinberger [this message]
2016-02-01 7:17 ` Bean Huo 霍斌斌 (beanhuo)
2016-02-01 8:28 ` Richard Weinberger
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=56A9E00E.1070706@nod.at \
--to=richard@nod.at \
--cc=adrian.hunter@intel.com \
--cc=beanhuo@micron.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=jasontian@micron.com \
--cc=karlzhang@micron.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=peterpandong@micron.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox