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, but add a brief warning that Fastmap actually makes UBI less robust. Signed-off-by: Jesper Nilsson <[email protected]> --- Changes in v2: - Add warning that Fastmap making UBI less robust drivers/mtd/ubi/Kconfig | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig index f0855ce08ed9..8912943b7142 100644 --- a/drivers/mtd/ubi/Kconfig +++ b/drivers/mtd/ubi/Kconfig @@ -57,12 +57,9 @@ config MTD_UBI_BEB_LIMIT Leave the default value if unsure. config MTD_UBI_FASTMAP - bool "UBI Fastmap (Experimental feature)" + bool "UBI Fastmap" default n help - Important: this feature is experimental so far and the on-flash - format for fastmap may change in the next kernel versions - Fastmap is a mechanism which allows attaching an UBI device in nearly constant time. Instead of scanning the whole MTD device it only has to locate a checkpoint (called fastmap) on the device. @@ -74,6 +71,10 @@ config MTD_UBI_FASTMAP images are still usable with UBI implementations without fastmap support. On typical flash devices the whole fastmap fits into one PEB. UBI will reserve PEBs to hold two fastmaps. + 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 speedup of the attach time is really important + and you can be sure that the NAND works as expected. If in doubt, say "N". -- 2.1.4 /^JN - Jesper Nilsson -- Jesper Nilsson -- [email protected]
