Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1637937 > unrolled thread

Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental Jesper Nilsson <jesper.nilsson@axis.com> - 2017-05-09 09:50 +0200
    Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental Richard Weinberger <richard@nod.at> - 2017-05-09 11:00 +0200

#1637937 — Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental

Hi Richard,

I'm still worried about this failure case, do we really
believe that the flash could fail in such a way that the
fastmap is corrupted in an undetectable way?

If we do detect corruption we should be no worse off
than earlier since we should ignore the fastmap, IIRC.

Could you please elaborate on the problem you were
thinking about?

Right now I'm hesitant to use fastmap in any production code,
even if it works with my current hardware, since there is no
guarantee that the flash chips won't get replaced with a
second source option down the line...

/Jesper


On Mon, Apr 03, 2017 at 01:17:36PM +0200, Jesper Nilsson wrote:
> Hi Richard,
> 
> On Thu, Mar 30, 2017 at 11:29:15PM +0200, Richard Weinberger wrote:
> > Jesper,
> > 
> > Am 30.03.2017 um 19:39 schrieb Jesper Nilsson:
> > >> 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
> > 
> > I'm not a native English speaker, but shouldn't this be
> > "...if speedup of the attach time is important ..."
> > 
> > > you can be sure that the NAND works as expected.
> > 
> > Looks fine!
> 
> As you saw I resent the patch with this formulation added.
> 
> However, after thinking about it (and with input from some coworkers),
> could we pinpoint the failure case a bit more here?
> 
> What is the exact problem behaviour on NAND chips that we're
> worried about, and in which case will UBI be less robust if
> we don't scan the full flash?
> 
> My first reaction was that this was a natural conclusion,
> but if the NAND flash is failing, we should either be in the
> case that the FASTMAP is corrupted or that the original data
> is corrupted. Both should be found by current implementation.
> Or am I missing additional failure cases here?
> 
> I getting a bit worried about using the feature at all,
> even if it seems to work right now...
> 
> > Thanks,
> > //richard
> 
> /^JN - Jesper Nilsson
> -- 
>                Jesper Nilsson -- jesper.nilsson@axis.com

/^JN - Jesper Nilsson
-- 
               Jesper Nilsson -- jesper.nilsson@axis.com

[toc] | [next] | [standalone]

#1637990

Jesper,

Am 09.05.2017 um 09:46 schrieb Jesper Nilsson:
> Hi Richard,
> 
> I'm still worried about this failure case, do we really
> believe that the flash could fail in such a way that the
> fastmap is corrupted in an undetectable way?
> 
> If we do detect corruption we should be no worse off
> than earlier since we should ignore the fastmap, IIRC.

In a perfect world, yes.

> Could you please elaborate on the problem you were
> thinking about?

e.g.
commit 74f2c6e9a47cf4e508198c8594626cc82906a13d
Author: Richard Weinberger <richard@nod.at>
Date:   Tue Jun 14 10:12:17 2016 +0200

    ubi: Be more paranoid while seaching for the most recent Fastmap

    Since PEB erasure is asynchornous it can happen that there is
    more than one Fastmap on the MTD. This is fine because the attach logic
    will pick the Fastmap data structure with the highest sequence number.

    On a not so well configured MTD stack spurious ECC errors are common.
    Causes can be different, bad hardware, wrong operating modes, etc...
    If the most current Fastmap renders bad due to ECC errors UBI might
    pick an older Fastmap to attach from.
    While this can only happen on an anyway broken setup it will show
    completely different sympthoms and makes finding the root cause much
    more difficult.
    So, be debug friendly and fall back to scanning mode of we're facing
    an ECC error while scanning for Fastmap.

    Cc: <stable@vger.kernel.org>
    Signed-off-by: Richard Weinberger <richard@nod.at>

> Right now I'm hesitant to use fastmap in any production code,
> even if it works with my current hardware, since there is no
> guarantee that the flash chips won't get replaced with a
> second source option down the line...

Fastmap is an aggressive optimization and makes finding issues much
harder.

Thanks,
//richard

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web