linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Matthieu CASTET <matthieu.castet@parrot.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: RE : UBI/UBIFS interrupted write page handling
Date: Tue, 28 Sep 2010 11:02:14 +0300	[thread overview]
Message-ID: <1285660934.2437.44.camel@localhost> (raw)
In-Reply-To: <4CA19DAE.7030402@parrot.com>

On Tue, 2010-09-28 at 09:47 +0200, Matthieu CASTET wrote:
> Artem Bityutskiy a écrit :
> > On Sun, 2010-09-26 at 20:58 +0300, Artem Bityutskiy wrote:
> >>> The test is still running, but because for each boot we got this slow
> >>> dump (take near 1 min), I expect others errors to take longer to
> >>> appear.
> >> Your PEB 20 contains almost all 0xFFs, but not quite, and NAND pages are
> >> read with ECC errors. I think this is a result of power cut during
> >> erasure.
> >>
> >> My new patch-set is trying to detect situations when we have a PEB which
> >> contains important data, but its VID header is corrupted. We try to
> >> preserve such PEBs instead of erasing. UBI would not spam so much if
> >> debugging was disabled.
> > 
> > Matthieu, thanks for testing the latest UBI changes. I wonder, do you
> > have issues with the follow-up fix I sent you. I just wonder if it is ok
> > for me to put these patches to linux-next or it is better to wait a
> > little?
> > 
> That's better : interrupt erased page are not put anymore in corrupted list.
> But I have problem with interrupt write :
> this night the test crashed [1].

Yeah, this should be fixed by forcing LEB refresh for the last LEBs of
journal heads. This problem exists long time. I'll work on this and send
you patches.

Then I'll push the patches to the linux-next. This means I'll re-base
once again the master branch - will you survive such frequent
re-basing :-) ? But once the stuff in the linux-next - I do not rebase
it.

We also have the outstanding gc_lnum problem - did you see it in new
ubifs?

Also I wanted to add re-try logic to UBI read path, so that we could try
to read several times if there is an ECC errors, because as you pointed,
re-trying sometimes helps. However, this also needs a fix in mtd, which
is currently in my l2 tree:
http://git.infradead.org/users/dedekind/l2-mtd-2.6.git/commit/755e723d39ac6975e6488298e129284e30d74823


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

  parent reply	other threads:[~2010-09-28  8:04 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-09 13:15 UBI/UBIFS interrupted write page handling Matthieu CASTET
2010-09-09 17:51 ` Artem Bityutskiy
2010-09-20 18:14   ` Artem Bityutskiy
2010-09-23 16:14     ` Matthieu CASTET
2010-09-23 18:35       ` Artem Bityutskiy
     [not found]         ` <F5C24FC168F95048BB6B9E0B13EB33152BA6F5304E@DIAMANT.xi-lite.lan>
2010-09-26 17:58           ` RE : " Artem Bityutskiy
2010-09-28  6:58             ` Artem Bityutskiy
2010-09-28  7:47               ` Matthieu CASTET
2010-09-28  8:02                 ` Matthieu CASTET
2010-09-28  8:02                 ` Artem Bityutskiy [this message]
2010-09-28 16:06                   ` Matthieu CASTET
2010-09-28 18:34                     ` Artem Bityutskiy
2010-10-04 13:12                   ` Matthieu CASTET
2010-10-18 10:21                     ` 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=1285660934.2437.44.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=matthieu.castet@parrot.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).