Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933421AbdC3KCB (ORCPT ); Thu, 30 Mar 2017 06:02:01 -0400 Received: from mail-lf0-f66.google.com ([209.85.215.66]:33576 "EHLO mail-lf0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932918AbdC3KBp (ORCPT ); Thu, 30 Mar 2017 06:01:45 -0400 Subject: Re: [RFC][PATCH] UBI: Make MTD_UBI_FASTMAP non-experimental To: Richard Weinberger , Jesper Nilsson , Artem Bityutskiy , David Woodhouse , Brian Norris , Boris Brezillon , Cyrille Pitchen , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org References: <20170329153836.GB29118@axis.com> <434195d8-d638-240d-8d63-50d033ea453a@nod.at> From: Marek Vasut Message-ID: <3f8d0417-5e7d-b7c8-ba83-9a87e774f97f@gmail.com> Date: Thu, 30 Mar 2017 12:01:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <434195d8-d638-240d-8d63-50d033ea453a@nod.at> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1287 Lines: 35 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 ? -- Best regards, Marek Vasut