Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752808AbdDCLRk (ORCPT ); Mon, 3 Apr 2017 07:17:40 -0400 Received: from bes.se.axis.com ([195.60.68.10]:51363 "EHLO bes.se.axis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751846AbdDCLRj (ORCPT ); Mon, 3 Apr 2017 07:17:39 -0400 Date: Mon, 3 Apr 2017 13:17:36 +0200 From: Jesper Nilsson To: Richard Weinberger Cc: Jesper Nilsson , Marek Vasut , Artem Bityutskiy , David Woodhouse , Brian Norris , Boris Brezillon , Cyrille Pitchen , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental Message-ID: <20170403111735.GV29118@axis.com> References: <20170329153836.GB29118@axis.com> <434195d8-d638-240d-8d63-50d033ea453a@nod.at> <3f8d0417-5e7d-b7c8-ba83-9a87e774f97f@gmail.com> <20170330173944.GJ29118@axis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-TM-AS-GCONF: 00 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1516 Lines: 46 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