Does UBI LEB-level access interlock happily with UBIfs access?

[Atlant Schmidt]

Artem:

  Thanks, but the key was in this line of my question:

> For the purposes of scrubbing-out *SINGLE BIT* errors,


  Single bit errors are below the threshold set by either
  current UBI software or newer NAND Flash chips that
  contain on-board ECC and set a "Rewrite recommended"
  Status Register bit.

  That's why I proposed doing the UBI-level LEB rewrites
  myself, any time even a single bit-flip was reported as
  being corrected.

  For software ECC done in the UBI code, I guess one
  strategy (as we discussed a few months back) is to
  modify the UBI code so it schedules a block for
  scrubbing even if a single-bit correctable error
  occurs.

  For ONFI Flash with hardware ECC, I'm not sure there
  is a solution; I don't see where the ONFI Flash reports
  "correctable error but not at the rewrite threshold";
  a read seems to either:

    o Succeed (with no or few corrections;
               no special report generated)

    o Succeed (with "Rewrite" being recommended)

    o Fail


  Maybe I'll ask Micron's tech-support folks if there's
  more info available than is made obvious in the
  datasheet.

                      Atlant

-----Original Message-----
From: Artem Bityutskiy [mailto:dedekind1 at gmail.com]
Sent: Friday, September 19, 2014 11:27 AM
To: Atlant Schmidt
Cc: linux-mtd at lists.infradead.org
Subject: Re: Does UBI LEB-level access interlock happily with UBIfs access?

On Tue, 2014-09-16 at 10:04 -0400, Atlant Schmidt wrote:
> Folks:
>
>   We use the ordinary MTD/UBI/UBIfs stack on our
>   Embedded Linux system.
>
>   For the purposes of scrubbing-out single bit errors,
>   I'd like to read through all of the LEBs stored in the
>   UBI device and whenever the ECC information indicates
>   that any correctable errors occurred, I'd like to
>   *RE-WRITE* that LEB (thereby forcing it to be scrubbed).
>   (Note: I might do this page-by-page rather than LEB-
>   by-LEB.)

Well, you may do something like

dd if=/dev/ubiX_Y of=/dev/null

For all volumes, and this will make UBI real all pages from all volumes
and whenever there was a bit-flip, schedule the LEB for scrubbing.

The volume table LEBs wont'd be read, though. To cover even that, you
one could introduce a special ioctl.

In case of fastmap, this ioctl would cover all the fatmap special LEBs
too.

>   But I would expect that because I'd have a hard
>   (impossible?) time doing an atomic read/re-write of a
>   LEB (or page), the UBIfs and my scrubber would interact
>   badly with my scrubber eventually corrupting the UBIfs
>   file system. Is there any easy way to interlock these
>   accesses (from the UBIfs and from my UBI-level scrubber)?
>   A way to temporarily suspend activity from the UBIfs?
>
>   One kludge that might work is that I'm operating in a
>   real-time environment. If I made my scrubbing requests
>   from a very high priority (higher than the "System"
>   tasks that run around Priority 50), could I be sure
>   my read + rewrite scrubbing requests would at least
>   enter the UBI's work queue immediately adjacent to
>   each other (and without UBIfs requests intermingled)?
>
>   Alternatively, I could probably dismount the UBIfs
>   before doing scrubbing, but I'd rather not have to
>   do that.

You do not need to do unmount anything with the above technique. If,
say, UBI scheduled an LEB 0:1 (volume 0, LEB 1) for scrubbing, and UBIFS
(which has volume 0 mounted) writes to LEB 1, UBI will block the writer
until the scrubbing finishes, so you do not have to worry.

HTH.

--
Best Regards,
Artem Bityutskiy


This e-mail and the information, including any attachments it contains, are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.