All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Pedro I. Sanchez" <psanchez@fosstel.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBIFS and MLC NAND Flash
Date: Thu, 08 Apr 2010 11:22:41 +0300	[thread overview]
Message-ID: <1270714961.6754.107.camel@localhost> (raw)
In-Reply-To: <4BA7A183.7040206@fosstel.com>

Hi,

On Mon, 2010-03-22 at 12:57 -0400, Pedro I. Sanchez wrote:
> Hello,
> 
> I have a few questions regarding this topic.
> 
> 1. The UBIFS FAQ has a summary of the state of the support for MLC NAND 
> flash here:
> 
>   http://www.linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_mlc
> 
> The question is, is this still the case? Does the FAQ reflect the 
> current state of affairs?

I think so.

> 2. I have several boards with MLC NAND flash running the Linux kernel 
> 2.6.29 and UBIFS. I am seeing a fairly large rate of file "corruption" 
> errors, files that all of a sudden become unreadable. Curiously enough, 
> they have been read-only files in all cases, program executables and 
> shared libraries.

Hmm. Do you do unclean power cuts?

> Would upgrading to a more recent kernel, or back porting the latest 
> UBIFS code, help? Shall I expect better support for MLC NAND flash in 
> the latest UBIFS code?

You did not specify whether you pulled the ubifs-v2.6.29.git tree. If
you did this, then your UBI/UBIFS should be the same as in the latest
kernels. Please, do this, although this will probably not solve your
corruption problems, but you'll have other bug-fixes we have made since
2.6.29 times.

Please, take a look here as well:
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_how_send_bugreport

Did you run MTD tests? If no, run them. You may have issues on driver/HW
levels.

Vs. "Shall I expect better support" - not as far as I know, because I
have not heard if anyone is working on this. But you could do that and
contribute.

> 3. I am also seeing other errors where it is the U-Boot or the Kernel 
> partitions that become corrupted. UBIFS is not involved there directly 
> since these partitions are at the mtd level and outside the UBI layer.
> 
> More specifically, my flash is partitioned as mtd0, mtd1, mtd2, mtd3, 
> mtd4. Only mtd4 has UBI/UBIFS on top. Is it possible that some flash 
> handling problems in UBIFS (mtd4) "spill over" other non-UBIFS mtd 
> partitions?

May be. Start with validating your MTD driver using MTD tests. This may
help you to narrow down the problem.

> 4. Other than minimizing flash writes, is there any other suggestion on 
> what to do to improve on the failure rate I see in the file system?

Not sure. You should carefully investigate you problems and find out the
nature of the failures, and then we can discuss that.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

  reply	other threads:[~2010-04-08  8:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-22 16:57 UBIFS and MLC NAND Flash Pedro I. Sanchez
2010-04-08  8:22 ` Artem Bityutskiy [this message]
2010-04-19 21:57   ` twebb
2010-04-19 23:52     ` Pedro I. Sanchez
2010-05-03 14:48       ` Pedro I. Sanchez
2010-05-04 14:17         ` Artem Bityutskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1270714961.6754.107.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=psanchez@fosstel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.