linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Pedro I. Sanchez" <psanchez@fosstel.com>
To: twebb <taliaferro62@gmail.com>
Cc: linux-mtd@lists.infradead.org, dedekind1@gmail.com
Subject: Re: UBIFS and MLC NAND Flash
Date: Mon, 19 Apr 2010 19:52:39 -0400	[thread overview]
Message-ID: <4BCCECC7.8000006@fosstel.com> (raw)
In-Reply-To: <i2odbdb2ea61004191457s58e5b816i1efdf694a1e2a24@mail.gmail.com>

twebb wrote:
>>> 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.
>>
>>
> 
> Pedro,
> I'm seeing very similar issues with MLC+UBIFS, though not only with
> read-only files.  Have you made any progress in your investigation or
> while trying Artem's suggestions?  I'm about to start digging into
> this and would be interested to hear about any issues you may have
> come across.  Do you have any opinion on whether this "corruption" is
> related to the information posted on the linux-mtd site at...
> http://www.linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_mlc ?
> 
> A few notes:
> - I do occasionally have power cuts, but my understanding was that
> UBI/UBIFS was very tolerant of that condition.
> - I use CONFIG_MTD_UBI_WL_THRESHOLD=256
> - I'm using linux-2.6.29
> 
> Thanks,
> twebb

I haven't had the opportunity to use 2.6.29 with the ubifs backport yet. 
However, I run my devices over an extended operational test and couldn't 
reproduce the errors. In this test I avoided any power cuts on purpose 
because I wanted to verify that the boards' software was not at fault 
during normal conditions.

I still see the errors in the deployed boards and these ones are subject 
to random power cuts. After analyzing the logs I conclude that there is 
a strong correlation between the power cuts and the corruption errors. 
The typical scenario is a board running fine for two months without 
interruption, then a power cut, and then upon reboot a myriad of UBIFS 
error messages show up (see sample following my signature)

I'm almost convinced now that power cuts are the culprit. I will be 
conducting test in the next few days to fully verify this. I'll post my 
results.

Thanks,

-- 
Pedro


Mar 16 00:58:22 blazepoint kernel: uncorrectable error : <3>UBI error: 
ubi_io_re
ad: error -74 while reading 2560 bytes from PEB 376:213720, read 2560 bytes
Mar 16 00:58:22 blazepoint kernel: UBIFS error (pid 1507): 
try_read_node: cannot
  read node type 1 from LEB 322:209624, error -74
Mar 16 00:58:22 blazepoint kernel: uncorrectable error : <3>UBI error: 
ubi_io_re
ad: error -74 while reading 2560 bytes from PEB 376:213720, read 2560 bytes
Mar 16 00:58:22 blazepoint kernel: UBIFS error (pid 1507): 
ubifs_check_node: bad
  CRC: calculated 0x5edaa128, read 0xacfe20eb
Mar 16 00:58:22 blazepoint kernel: UBIFS error (pid 1507): 
ubifs_check_node: bad
  node at LEB 322:209624
Mar 16 00:58:22 blazepoint kernel: UBIFS error (pid 1507): 
ubifs_read_node: expe
cted node type 1
Mar 16 00:58:22 blazepoint kernel: UBIFS error (pid 1507): do_readpage: 
cannot r
ead page 261 of inode 3463, error -117
Mar 16 00:58:22 blazepoint kernel: uncorrectable error : <3>UBI error: 
ubi_io_re
ad: error -74 while reading 2560 bytes from PEB 376:213720, read 2560 bytes

  reply	other threads:[~2010-04-19 23:52 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
2010-04-19 21:57   ` twebb
2010-04-19 23:52     ` Pedro I. Sanchez [this message]
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=4BCCECC7.8000006@fosstel.com \
    --to=psanchez@fosstel.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=taliaferro62@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).