From: Jesper Nilsson <jesper.nilsson@axis.com>
To: Marek Vasut <marek.vasut@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
Jesper Nilsson <jespern@axis.com>,
Artem Bityutskiy <dedekind1@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Boris Brezillon <boris.brezillon@free-electrons.com>,
Cyrille Pitchen <cyrille.pitchen@atmel.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental
Date: Thu, 30 Mar 2017 19:39:44 +0200 [thread overview]
Message-ID: <20170330173944.GJ29118@axis.com> (raw)
In-Reply-To: <3f8d0417-5e7d-b7c8-ba83-9a87e774f97f@gmail.com>
Hi Richard, Marek,
On Thu, Mar 30, 2017 at 12:01:41PM +0200, Marek Vasut wrote:
> On 03/29/2017 10:04 PM, Richard Weinberger wrote:
> > Jesper,
> >
> > Am 29.03.2017 um 17:38 schrieb Jesper Nilsson:
> >> MTD_UBI_FASTMAP has been set as experimental since it
> >> was merged back in 2012.
> >>
> >> There hasn't been much change in the format,
> >> so we can consider the feature stable and start
> >> being careful about breaking the format.
> >> (This is somewhat of a pre-requisite for anyone actually
> >> using the feature in the real world and depending on it)
> >>
> >> Drop the experimental note and the warning text about
> >> the on-flash format not being finalized.
> >
> > I fully agree, we can drop this note. But we have to add another
> > one.
> > While Fastmap is a nice feature to speed-up the attach time it
> > comes with a cost. It makes UBI less robust. I saw issues
> > on NAND chips which misbehaved slightly where UBI was able to
> > recover when using a full scan but not when Fastmap was used.
> > The UBI full scan code is paranoid and can sort out problems
> > very early, with Fastmap enabled you lose this valuable property.
> >
> > So, users should enable Fastmap only when they absolutely need
> > a very fast attach time and be very sure that the NAND works as
> > expected.
>
> So we should document this with a big fat warning and set fastmap to
> default=n ?
Does this sound reasonable?
Note that this feature makes UBI less robust, since Fastmap does not scan
the full flash, which might lead to problems on misbehaving NAND chips.
Only enable this if the speedup in attach is really important and
you can be sure that the NAND works as expected.
> Best regards,
> Marek Vasut
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nilsson@axis.com
next prev parent reply other threads:[~2017-03-30 17:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 15:38 [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental Jesper Nilsson
2017-03-29 20:04 ` Richard Weinberger
2017-03-30 10:01 ` Marek Vasut
2017-03-30 17:39 ` Jesper Nilsson [this message]
2017-03-30 21:29 ` Richard Weinberger
2017-03-31 21:23 ` [PATCH v2] " Jesper Nilsson
2017-04-03 11:17 ` [RFC][PATCH] " Jesper Nilsson
2017-05-09 7:46 ` Jesper Nilsson
2017-05-09 8:53 ` 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=20170330173944.GJ29118@axis.com \
--to=jesper.nilsson@axis.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@atmel.com \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=jespern@axis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=richard@nod.at \
/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