From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: "Karl Zhang 张双锣 (karlzhang)" <karlzhang@micron.com>
Cc: "Bean Huo 霍斌斌 (beanhuo)" <beanhuo@micron.com>,
"Iwo Mergler" <Iwo.Mergler@netcommwireless.com>,
"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
"dedekind1@gmail.com" <dedekind1@gmail.com>,
"richard@nod.at" <richard@nod.at>,
"shuangshuo@gmail.com" <shuangshuo@gmail.com>,
"rnd4@dave-tech.it" <rnd4@dave-tech.it>,
"Jeff Lauruhn (jlauruhn)" <jlauruhn@micron.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"Stefan Roese" <sr@denx.de>,
"dwmw2@infradead.org" <dwmw2@infradead.org>
Subject: Re: UBI/UBIFS: dealing with MLC's paired pages
Date: Fri, 25 Sep 2015 10:56:16 +0200 [thread overview]
Message-ID: <20150925105616.3afa23d1@bbrezillon> (raw)
In-Reply-To: <D067BF0533BDBE4F821CF557AAAE78443B96DEA8@NTXXIAMBX01.xacn.micron.com>
On Fri, 25 Sep 2015 08:30:23 +0000
Karl Zhang 张双锣 (karlzhang) <karlzhang@micron.com> wrote:
> Hi Boris
>
> Something else suggestions.
>
> We know that using the OOB area to store UBI metadata(Backup data) is not a good idea, this is just a thinking, and also do a little work to implement it and verification .
>
> For paired page issue from MLC is troublesome, we are trying our best to deal with it. Although attempt to use some bad ideas.
>
> > > Only NAND provides an OOB area.
> Some devices(NOR) do not have OOB, simultaneously, they do not have paired page issue, right? I think they do not need to store a redundant metadata to anywhere.
> AFAIK , only MLC(TLC maybe) NAND need store some metadata for another copy, and try to protected it by ECC.
>
> But, if OOB have some unused area (at least 48 bytes) and the chip has paired page issue , could we take a little advantage of them to reduce UBI fail rate?
>
> Above, is just some thinking , wish we can have some better solutions.
> As Bean said, most customer do not want UBIFS crash, and so do we.
>
> Thanks to your patient to point out my wrong opinion.
Don't be sorry, and there's no wrong opinion: the whole point of this
discussion is sharing our ideas and arguing to find the best solution.
Regarding the use of extra OOB bytes, I'll follow Richard's opinion:
let's keep it as a 'last resort' solution if we fail to find an
acceptable alternative.
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-09-25 8:57 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <A765B125120D1346A63912DDE6D8B6310BF4CAA8@NTXXIAMBX02.xacn.micron.com>
2015-09-25 7:30 ` UBI/UBIFS: dealing with MLC's paired pages Boris Brezillon
2015-09-25 8:25 ` Bean Huo 霍斌斌 (beanhuo)
2015-09-25 8:35 ` Richard Weinberger
2015-09-25 8:48 ` Boris Brezillon
2015-09-25 8:30 ` Karl Zhang 张双锣 (karlzhang)
2015-09-25 8:56 ` Boris Brezillon [this message]
2015-09-17 13:22 Boris Brezillon
2015-09-17 15:20 ` Artem Bityutskiy
2015-09-17 15:46 ` Boris Brezillon
2015-09-17 16:47 ` Richard Weinberger
2015-09-18 7:17 ` Andrea Scian
2015-09-18 7:41 ` Boris Brezillon
2015-09-18 7:54 ` Artem Bityutskiy
2015-09-18 7:57 ` Bityutskiy, Artem
2015-09-18 9:38 ` Andrea Scian
2015-09-24 1:57 ` Karl Zhang 张双锣 (karlzhang)
2015-09-24 6:31 ` Richard Weinberger
2015-09-24 7:43 ` Boris Brezillon
2015-09-24 9:44 ` Stefan Roese
2015-09-29 11:19 ` Richard Weinberger
2015-09-29 12:51 ` Boris Brezillon
2015-10-23 8:14 ` Boris Brezillon
2015-10-27 20:16 ` Richard Weinberger
2015-10-28 9:24 ` Boris Brezillon
2015-10-28 10:44 ` Michal Suchanek
2015-10-28 11:14 ` Boris Brezillon
2015-10-28 15:50 ` Michal Suchanek
2015-10-28 12:24 ` Artem Bityutskiy
2015-10-30 8:15 ` Boris Brezillon
2015-10-30 8:21 ` Boris Brezillon
2015-10-30 8:50 ` Bean Huo 霍斌斌 (beanhuo)
2015-10-30 9:08 ` Artem Bityutskiy
2015-10-30 9:45 ` Boris Brezillon
2015-10-30 10:09 ` Artem Bityutskiy
2015-10-30 11:49 ` Michal Suchanek
2015-10-30 12:47 ` Artem Bityutskiy
2015-10-30 11:43 ` Artem Bityutskiy
2015-10-30 11:59 ` Richard Weinberger
2015-10-30 12:29 ` Artem Bityutskiy
2015-10-30 12:31 ` Bityutskiy, Artem
2015-10-30 12:30 ` Boris Brezillon
2015-10-30 12:41 ` Artem Bityutskiy
2015-10-28 12:06 ` Artem Bityutskiy
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=20150925105616.3afa23d1@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=Iwo.Mergler@netcommwireless.com \
--cc=beanhuo@micron.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=jlauruhn@micron.com \
--cc=karlzhang@micron.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=rnd4@dave-tech.it \
--cc=shuangshuo@gmail.com \
--cc=sr@denx.de \
/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.