From 6c394bdc5d9f15d407f46de13a6194a1f7ec10ea Mon Sep 17 00:00:00 2001 From: Artem Bityutskiy Date: Thu, 20 Oct 2011 13:30:14 +0300 Subject: [PATCH] UBIFS: move MLC info from FAQ to docs And add a section about paired pages issue. Signed-off-by: Artem Bityutskiy --- doc/ubifs.xml | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++ faq/ubifs.xml | 87 ------------------------------------------- 2 files changed, 100 insertions(+), 87 deletions(-) diff --git a/doc/ubifs.xml b/doc/ubifs.xml index dd3d37c..05351ea 100644 --- a/doc/ubifs.xml +++ b/doc/ubifs.xml @@ -15,6 +15,7 @@
  • Big red note
  • Overview
  • Power-cuts tolerance
    • +
  • UBIFS and MLC NAND flash
  • Source code
  • Mailing list
  • User-space tools
    • @@ -202,6 +203,105 @@ and +

    UBIFS and MLC NAND flash

    + +

    UBIFS authors never tested UBI/UBIFS on MLC flash devices. Let's consider +some specific aspects of MLC NAND flashes:

    + + + + +

    Source code

    UBIFS is in mainline since 17 July 2008 and the first kernel release which diff --git a/faq/ubifs.xml b/faq/ubifs.xml index 7d0af9a..8dafead 100644 --- a/faq/ubifs.xml +++ b/faq/ubifs.xml @@ -14,7 +14,6 @@

    Table of contents

    1. How do I enable UBIFS?
      2. -
    2. May UBIFS be used on MLC NAND flash?
    3. How do I mount UBIFS?
    4. How do I create an UBIFS image?
    5. May an empty UBI volume be mounted?
      6. @@ -61,92 +60,6 @@ the kernel or be built as a kernel module.

      -

      May UBIFS be used on MLC NAND flash?

      - -

      UBIFS authors never tested UBI/UBIFS on MLC flash devices. Let's consider -some specific aspects of MLC NAND flashes:

      - -
        -
      • MLC NAND flashes are more "faulty" than SLC, so they use stronger - ECC codes; these ECC codes often occupy whole OOB area (as do the - ECC codes on some newer SLC flashes, which are more error-prone than - previous generations of flash); this is not a problem for UBI/UBIFS, - because neither UBIFS nor UBI use OOB area;
        • - -
      • when the data are written to an eraseblock, they have to be written - sequentially, from the beginning of the eraseblock to the end of it; - this is also not a problem because it is exactly what UBI and UBIFS do - (see also this section);
        • - -
      • MLC flashes have rather short eraseblock life-cycles of just a few - thousand erase cycles; this is not a problem because UBI uses a - deterministic wear-leveling algorithm - (see this section);
        • - -
      • MLC flashes exhibit bit flips as a result of "program disturb" and - "read disturb" errors (see - here). - Note that SLC flashes have these same errors, but they are much more - common on MLC: -
          -
        • NAND flashes have a so called "read-disturb" property, which - means that a NAND page read operation may introduce a permanent - bit change; the ECC code would fix it, but more read operations - may introduce more bit changes and soft ECC errors may turn - into hard ECC errors; however, when these errors occur on the - same page that is being read, this should not be a problem - because UBI is doing scrubbing; in other words, once UBI notices - that there is a correctable bit-flip in an eraseblock, it moves - the contents of this physical eraseblock to a different physical - eraseblock, and re-maps the corresponding logical eraseblock to - the new physical eraseblock; so UBI refreshes the data and gets - rid of bit-flips, thus improving data integrity.
          • - -
        • "Read-disturb" errors can also occur on a page other - that the one being read, but which is within the same - eraseblock. This is not a problem if the read operations are - spread around somewhat evenly within the eraseblock, since the - bit-flip will soon be detected and corrected through the - "scrubbing" process described above. However if a particular - page within a block is rarely read, scrubbing will not have a - chance to fix errors, and they may accumulate over time until - they are unfixable. This is very similar the next problem:
          • - -
        • NAND flashes also have a "program-disturb" property, - which means that if you program a NAND page, you may introduce - a bit-flip in a different NAND page. The bit change can be - fixed by ECC, but with time the changes may accumulate - and become unfixable. Current UBI bit-flip handling only - partially helps here, because it is passive, which means that - UBI notices bit-flips only when performing users' read requests. - So if you never read the NAND page which accumulates bit-flips, - UBI will never notice this. One solution to these problems is - to implement a kind of "flash crawler" which would read all of - the NAND pages in the background from time to time, making UBI - notice and fix bit-flips. However, this is not implemented - today. -
          • -
        • -
      - -

      There is another aspect of MLC flashes which may need closer attention: the -"paired pages" problem (e.g., see -this -Power Point presentation). Namely, MLC NAND pages are coupled in a sense -that if you cut power while writing to a page, you corrupt not only this page, -but also one of the previous pages which is paired with the current one. For -example, pages 0 and 3, 1 and 4, 2 and 5, 3 and 6 in and so on (in the same -eraseblock) may be paired (page distance is 4, but there may be other -distances). So if you write data to, say, page 3 and cut the power, you may -end up with corrupted data in page 0. UBIFS is not ready to handle this -problem at the moment and this needs some work.

      - -

      Nevertheless, UBIFS authors never worked with real raw MLC NAND flash, so we -might have missed or misinterpreted some MLC NAND aspects. Any feed-back is -appreciated.

      - - -

      How do I mount UBIFS?

      The modern way of mounting UBIFS is mounting UBI volume character device -- 2.50.1