From patchwork Tue Oct 9 16:23:01 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Weinberger X-Patchwork-Id: 190359 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 32BE02C0095 for ; Wed, 10 Oct 2012 03:24:04 +1100 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1TLcaS-0002uS-GZ; Tue, 09 Oct 2012 16:23:16 +0000 Received: from a.ns.miles-group.at ([95.130.255.143] helo=radon.swed.at) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1TLcaO-0002t6-DU for linux-mtd@lists.infradead.org; Tue, 09 Oct 2012 16:23:13 +0000 Received: (qmail 10120 invoked by uid 89); 9 Oct 2012 19:50:50 -0000 Received: by simscan 1.3.1 ppid: 10109, pid: 10116, t: 0.1017s scanners: attach: 1.3.1 clamav: 0.96.5/m:53 Received: from unknown (HELO localhost.localdomain) (richard@nod.at@212.186.22.124) by radon.swed.at with ESMTPA; 9 Oct 2012 19:50:50 -0000 From: Richard Weinberger To: linux-mtd@lists.infradead.org Subject: [PATCH] mtd-www: Add fastmap doc Date: Tue, 9 Oct 2012 18:23:01 +0200 Message-Id: <1349799781-5132-1-git-send-email-richard@nod.at> X-Mailer: git-send-email 1.7.11.5 In-Reply-To: References: X-Spam-Note: CRM114 invocation failed X-Spam-Score: -1.9 (-) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-1.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: thomas.petazzoni@free-electrons.com, Richard Weinberger , computersforpeace@gmail.com, dedekind1@gmail.com X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Add documentation on fastmap to mtd-www. Signed-off-by: Richard Weinberger --- doc/ubi.xml | 118 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 115 insertions(+), 3 deletions(-) diff --git a/doc/ubi.xml b/doc/ubi.xml index 6bea323..13b8174 100644 --- a/doc/ubi.xml +++ b/doc/ubi.xml @@ -46,6 +46,7 @@ +
  • Fastmap
  • More documentation
    • @@ -758,8 +759,12 @@ for detailed information.

    Unfortunately, UBI scales linearly in terms of flash size. UBI initialization time linearly depends on the number of physical eraseblocks on the flash. This means that the larger is the flash, the more time it takes for -UBI to initialize (i.e., to attach the MTD device). The initialization time -depends on the flash I/O speed and (slightly) on the CPU speed, because:

    +UBI to initialize (i.e., to attach the MTD device). +Note: Starting with Linux v3.7 UBI offers an optional and experimental feature, +called "fastmap", which allows attaching in nearly constant time, +see Fastmap. +The initialization time depends on the flash I/O speed and (slightly) on the +CPU speed, because:

    • UBI scans the MTD device when attaching - it reads the erase EC and @@ -1170,7 +1175,114 @@ means that all data has been written to the flash media), otherwise it selects the PEB with lower sequence number(P1). Of course, UBI has to read the LEB contents in order to check the CRC-32 checksum.

      - +

      Fastmap

      +

      +Fastmap is an experimental and optional UBI feature, which can be enabled +by setting CONFIG_MTD_UBI_FASTMAP to 'y'. +Once enabled UBI evaluates the module parameter +"fm_autoconvert". If it is set to 1 (default is 0) UBI automatically enables +fastmap for any attached image. This means UBI creates a new internal +volume with the fastmap data such that next time the fast attach mode can be +used. +In the default configuration UBI will use the information stored in this +fastmap volume to accelerate the attach procedure. +If you want to test fastmap, set fm_autoconvert to 1 and attach a volume. +

      + +The following settings are possible: + + + + + + + + + + + + + + + + + + + + + + + + + + +
      CONFIG_MTD_UBI_FASTMAPfm_autoconvertResult
      n0fastmap is completely disabled
      y0UBI will attach by fastmap if one exists on an image, +but no fastmap will be installed on images without a fastmap
      y1UBI will attach by fastmap if one exists on an image, a fastmap +is automatically installed on all attached images
      + +

      Backwards compatibility

      +

      The fastmap on-disk data structure makes use of delete compatible volumes, +therefore fastmap enabled images are fully backwards compatible with UBI +implementations which do not support fastmap. The kernel will remove the fastmap +volumes and continue with scanning. +This includes not only v3.6- but also v3.7+ with this option disabled. +

      + +

      Technical design

      + +

      A on-disk fastmap contains all information needed to attach the whole image, +namely all erase counter values, a list of all PEBs and their state, a list of +all volumes and their current EBA, ... +To avoid too many writes of the fastmap, it also contains a list of PEBs which +may have changed and need a full scan while attaching. +This list is called "fastmap pool" and has a fixed sized, 5% of the total +amount of PEBs. Using this technique UBI needs to write the fastmap only if the +pool contains no free PEBs. Otherwise it would have to write the fastmap each +time the EBA of a volume has changed.

      + +

      A fastmap consists of a super block (also known as anchor PEB) and payload +data which can live on any PEB. +The anchor PEB has to be located within the first 64 PEBs on the MTD device. +It contains pointers to the remaining PEBs which carry the actual fastmap +data. On modern NAND chips the whole fastmap fits into a single PEB. +Hence, the anchor PEB points to itself. +After loading the fastmap data, UBI attach information structure is created +from it. + +The attach process works as follows: +

        +
      1. UBI tries to find the fastmap anchor PEB, + if no anchor PEB was found UBI performs traditional full scan
        2. +
      2. It follows the pointers stored in the anchor PEB and reads + the fastmap payload data
        3. +
      3. Then it performs a traditional scan only on PEBs in the pool + instead of all PEBs
        4. +
      +If UBI detects that the used fastmap is invalid or corrupted it automatically +falls back to scanning mode and performs a full scan. +Using a CRC32 checksum and consistency checks of the internal UBI structures +UBI is able to detect whether a fastmap is invalid or not. +

      + +

      +A fastmap is written to the devices each time the fastmap pool becomes full +(no free PEBs are available), the volume layout changes or the image is +detached. One may wonder why writing at detach time is needed. +If UBI would not write a new fastmap at detach time all erase counter +modifications since the last fastmap write are lost. +

      + +

      Overhead

      +

      If fastmap enabled UBI will reserve enough PEBs to carry two complete +fastmaps. In practice on modern NAND chips two PEBs are reserved for fastmap. +

      +

      +There is also some runtime overhead, to guarantee that the new fastmap is valid +and conistent UBI has to take care that all IO which would cause EBA changes +are blocked while attaching. Depending on flash chips this can take up to one +second. Therefore, fastmap makes only sense on fast and large flash devices +where a full scan takes too long. E.g. On 4GiB NAND chips a full scan takes +several seconds whereas a fast attach needs less than one second.

      More documentation