From patchwork Sun Feb 16 20:04:01 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ezequiel Garcia X-Patchwork-Id: 320810 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:770:15f::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id CA73B2C009E for ; Mon, 17 Feb 2014 07:05:27 +1100 (EST) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WF7xP-0001Pf-Ns; Sun, 16 Feb 2014 20:04:55 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WF7xO-0007Hx-1m; Sun, 16 Feb 2014 20:04:54 +0000 Received: from top.free-electrons.com ([176.31.233.9] helo=mail.free-electrons.com) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WF7xE-0007Fm-JS for linux-mtd@lists.infradead.org; Sun, 16 Feb 2014 20:04:46 +0000 Received: by mail.free-electrons.com (Postfix, from userid 106) id 4E7FA922; Sun, 16 Feb 2014 21:04:35 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.free-electrons.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.3.2 Received: from localhost.localdomain (unknown [190.2.98.212]) by mail.free-electrons.com (Postfix) with ESMTPA id B4F847AD; Sun, 16 Feb 2014 21:04:31 +0100 (CET) From: Ezequiel Garcia To: Subject: [PATCH v6 3/3] UBI: Add block interface documentation Date: Sun, 16 Feb 2014 17:04:01 -0300 Message-Id: <1392581041-8099-4-git-send-email-ezequiel.garcia@free-electrons.com> X-Mailer: git-send-email 1.8.1.5 In-Reply-To: <1392581041-8099-1-git-send-email-ezequiel.garcia@free-electrons.com> References: <1392581041-8099-1-git-send-email-ezequiel.garcia@free-electrons.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140216_150444_947202_85E26E08 X-CRM114-Status: GOOD ( 16.82 ) X-Spam-Score: 1.1 (+) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (1.1 points) pts rule name description ---- ---------------------- -------------------------------------------------- 2.9 KHOP_BIG_TO_CC Sent to 10+ recipients instaed of Bcc or a list 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Thomas Petazzoni , Mike Frysinger , Artem Bityutskiy , Richard Weinberger , Michael Opdenacker , Ezequiel Garcia , Piergiorgio Beruto , Brian Norris , David Woodhouse , Willy Tarreau X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.15 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" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Signed-off-by: Ezequiel Garcia --- Applies on top of mtd-www git repo. doc/general.xml | 4 ++++ doc/ubi.xml | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ faq/ubi.xml | 16 +++++++------- 3 files changed, 79 insertions(+), 8 deletions(-) diff --git a/doc/general.xml b/doc/general.xml index 31ea243..d5af815 100644 --- a/doc/general.xml +++ b/doc/general.xml @@ -182,6 +182,10 @@ use block-based file systems on top of bare flashes using In other words, please, do not use mtdblock unless you know exactly what you are doing.

+

Instead, you may find the block interface provided by UBI +useful. Please refer to the UBI section for more +details.

+

There is also a read-only version of this driver which doesn't have the capacity to do the caching and erase/writeback, mainly for use with uCLinux where the extra RAM requirement was considered too large.

diff --git a/doc/ubi.xml b/doc/ubi.xml index f55c04a..dd06927 100644 --- a/doc/ubi.xml +++ b/doc/ubi.xml @@ -47,6 +47,7 @@
  • Fastmap
    • +
  • Block interface
  • More documentation
    • @@ -173,6 +174,11 @@ because:

    mechanisms). +

    UBI also provides a block interface that allows regular, block-oriented +filesystems to be mounted on top of an UBI volume. This is possible because UBI +handles bad-blocks transparently. This block interface does not peform any +wear-leveling, and therefore write support hasn't been implemented.

    +

    There is an additional driver called gluebi which emulates MTD devices on top of UBI volumes. This looks a little strange, because UBI works on top of an MTD device, then gluebi emulates other MTD devices @@ -236,6 +242,8 @@ sub-directory.

    devices (the opposite to what ubiattach does);
  • ubimkvol - creates UBI volumes on UBI devices;
  • ubirmvol - removes UBI volumes from UBI devices;
    • +
  • ubiblkvol - manages block interfaces for UBI volumes. + See here for more information;
  • ubiupdatevol - updates UBI volumes; this tool uses the UBI volume update feature which leaves the volume in "corrupted" state if the update was interrupted; @@ -1261,6 +1269,65 @@ 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.

    +

    Block interface

    + +

    UBI allows to create a block device on top of each UBI volume. The block +interface implementation currently has the following limitations: + +

      +
    • Read-only operation.
      • +
    • 1-to-1 mapping between block sectors and logical eraseblocks. + In other words, no wear-leveling is provided.
      • +
    • Serialized and uncached operation.
      • +

    + +

    Write-support is still under discussion and might be implemented in a +near future.

    + +

    Regarding the serialized, uncached operation, keep in mind the NAND driver core +already serializes all I/O anyway. In addition, filesystems usually provides +a much better caching. For these reasons, it's expected that these limitations +won't impact performance heavily.

    + +

    Despite these limitations, a block interface is still very useful to mount +read-only, regular filesystems on top of UBI volumes. This is the case +of squashfs, which can be used as a lightweigth read-only rootfs on a NAND +device.

    + +

    Usage

    +

    Attaching and detaching a block interface on a UBI volume is fairly easy. +You can do this either by using the block UBI module parameter +or with the ubiblkvol user-space tool.

    + +

    In order to attach a block device on bootup time (e.g. to mount the rootfs +on such a block device) you can specify the block parameter as +a kernel boot arguments:

    + +

    ubi.mtd=5 ubi.block=0,0 root=/dev/ubiblock0_0

    + +

    There are several ways if specifying a volume:

    +
      +

    • Using the UBI volume path:

      + ubi.block=/dev/ubi0_0
      • + +

    • Using the UBI device, and the volume name:

      + ubi.block=0,rootfs
      • + +

    • Using both UBI device number and UBI volume number:

      + ubi.block=0,0
      • +
    + +

    If you've built UBI as a module you can use this parameter at module insertion +time:

    + +$ modprobe ubi mtd=/dev/mtd5 block=/dev/ubi0_0 + +

    A block interface can also be attached/detached dynamically at runtime, using +the ubiblkvol user-space tool:

    + +

    $ ubiblkvol --attach /dev/ubi0_0

    +

    $ ubiblkvol --detach /dev/ubi0_0

    +

    More documentation

    Unfortunately, there are no thorough and strict UBI documents. But there is diff --git a/faq/ubi.xml b/faq/ubi.xml index 2832928..69f5495 100644 --- a/faq/ubi.xml +++ b/faq/ubi.xml @@ -18,6 +18,7 @@

  • How do I create/delete UBI volumes?
  • How do I run JFFS2 on top of an UBI volume?
  • Can I run ext2 on top of UBI?
    • +
  • Can I run squashfs on top of UBI?
  • Do I have to format my empty flash before running UBI on top of it?
  • How do I erase flash and preserve erase counters?
  • How do I create UBI images?
    • @@ -159,16 +160,15 @@ Please, read the big red note and overview documentation sections to realize why.

    -

    But it is much easier to implement FTL on top of UBI than on top of MTD, -because UBI takes care about many flash complexities and makes it -possible to concentrate on on upper-level issues rather then solving flash -media problems like wear-leveling, bit-flips, bad eraseblocks, etc.

    - -

    -This e-mail describes an idea of a simple FTL layer on top of UBI.

    +

    However, given UBI takes care of many flash complexities, it provides a +bad-block-free block interface on top of UBI volumes. This feature is useful to +mount read-only filesystems.

    +

    Can I run squashfs on top of UBI?

    +

    Yes. UBI allows to create a read-only block interface on top of a UBI volume +which is suitable for read-only block-oriented filesystems, such as squashfs. +See the UBI block interface section for more details.

    Do I have to format my empty flash before running UBI on top of it?